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1.0 Introduction 


1.1 Joint Advanced Distributed Simulation Overview 

The Joint Advanced Distributed Simulation Joint Test and Evaluation (JADS JT&E) was 
chartered by the Deputy Director, Test, Systems Engineering and Evaluation (Test and 
Evaluation), Office of the Under Secretary of Defense (Acquisition and Technology) in October 
1994 to investigate the utility of advanced distributed simulation (ADS) technologies for support 
of developmental test and evaluation (DT&E) and operational test and evaluation (OT&E). The 
program is Air Force led, with Army and Navy participation. The Joint Test Force (JTF) 
manning includes 23 Air Force, 13 Army, and 2 Navy. Science Applications International 
Corporation and Georgia Tech Research Institute provide contracted technical support. The 
program is nominally scheduled for five years. 

The JADS JT&E charter focuses the evaluation of utility on three issues: (1) What is the present 
utility of ADS, including distributed interactive simulation (DIS), for T&E? (2) What are the 
critical constraints, concerns, and methodologies when using ADS for T&E? (3) What are the 
requirements that must be introduced into ADS systems if they are to support a more complete 
T&E capability in the future. From these issues, objectives and measures have been developed to 
guide the evaluation. 

The JADS JT&E is directly investigating ADS applications in three slices of the T&E spectrum: 
a System Integration Test (SIT) which explores ADS support of air-to-air missile testing, an End- 
To-End (ETE) Test which explores ADS support for command, control, communications, 
computers, and intelligence, surveillance and reconnaissance (C4ISR) testing, and an Electronic 
Warfare (EW) Test which explores ADS support for EW testing. Each test will apply the JADS 
objectives and measures as appropriate to conduct their evaluation. The JTF is also chartered to 
observe, or participate at a modest level, in ADS activities sponsored and conducted by other 
agencies in an effort to broaden conclusions developed in the three dedicated test areas. 

The JADS ETE Test is the subject of this report and is described in the next section; the 
following is a brief synopsis of the SIT and EW tests. 

The Srr evaluated the utility of using ADS to support cost-effective testing of an integrated 
missile weapon/launch aircraft system in an operationally realistic scenario. The SIT also 
evaluated the capability of the JADS Test Control and Analysis Center (TCAC) to control a 
distributed test of this type and to remotely monitor and analyze test results. The SIT consisted 
of two phases, each of which culminated in three flight missions. The missions simulated a 
single shooter aircraft launching an air-to-air missile against a single target aircraft. In the 
Linked Simulators Phase (LSP), the shooter, target, and missile were all represented by 
simulators. In the Live Fly Phase (LFP), the shooter and target were represented by live aircraft 
and the missile by a simulator. 
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The EW test will evaluate the utility of ADS in a distributed EW test environment. The first 
p ase is open air testing to develop a performance baseline for two subsequent test phases. The 
^st distributed test phase employs a linked architecture utilizing Department of Defense’s 
( oD) high level architecture (HLA) which includes a digital simulation model of the ALQ-131 
self-protection jammer, threat simulation facilities, and constructive models which support 
replication of the open air environment. In the second phase, an installed systems test facility is 
substituted for the digital model. In both distributed test architectures, system performance data 
will be compared with live fly data for verification and validation (V&V). 

1.2 Test Overview 


he ETE test is designed to evaluate the utility of ADS to support testing of C4ISR systems. The 
test will use the developmental and operational testing issues for the Joint Surveillance Target 
ttack Radar System (Joint STARS) to conduct its T&E utility evaluation in an ADS-enhanced 
test environment. Additionally, ETE also includes an evaluation of JADS Test Control and 
nalysis Center’s (TCAC) capability to control a distributed test of this type and remotely 
monitor and analyze test results ^ 


distributed simulation to assemble an enhanced environment to be used for 
testing C4ISR systems. The intent is to provide a complete, robust set of interfaces from sensor 
to weapon system including the additional intermediate nodes that would be found in a tactical 
engagement. The test will trace a thread of the complete battlefield process from target detection 
to target ^signment and engagement at corps level using ADS. It will allow the tester to 
evaluate the thread as a whole or the contribution of any of the parts individually and to evaluate 
what effects an operationally realistic environment has on the system under test. 


CTADC-*"!. ™ evaluation of ADS enhancements to the testing of Joint 

toitatton identiM in the Joint STARS multi-service operational test and evaluation 
(MOT&E) plan WM the inahihty to test Joint STARS ability to support a notional corps area of 
interest. As a result of this limitation, many of the MOT&E measures were or will be collected 
under conditions short of the projected Joint STARS operational environment 


^us, the ETE is deigned to add additional entities in a seamless manner to the battlefield seen 
by the Joint STARS. In addition, adding some of the complementary suite of other C4I and 

wM^n systems with which Joint STARS would interact will enable the test team to evaluate the 
Utility of an ADS-enhanced test environment. 


The test concept (Figure 1) is to use ADS to supplement the operational environment the E-8C 
and ground station module (GSM) operators would experience. By mixing the available live 
targets with targets generated by a constructive model, a battle array that approximates the major 
systems present in a notional corps area of interest can be presented. Additionally by 
constructing a network with nodes representing appropriate C4I and weapon systems, a more 
robust cross section of players is ayailable with which the E-8C and GSM operators can interact 
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FDC - fire direction center 


SCDL - surveillance control data link 


Figure 1. EXE Test Concept 

Several components are required to create the ADS-enhanced operational environment that will 
be used in the ETE. In addition to Joint STARS, the ETE will require a validated simulation 
capable of generating entities that will represent the elements in the rear of a threat force. Also, 
simulations of the Joint STARS moving target indicator (MTI) radar and synthetic aperture radar 
(SAR) will be used to insert the simulated entities into the radar stream aboard the E-8C while it 
is flying a live mission. Other capabilities used to support the test include a subset of the Army’s 
analysis and control element (ACE), simulations or subsets of the Army’s artillery command and 
control process, and a simulation of the Army’s Advanced Tactical Missile System (ATACMS). 
Communications among these simulations will be accomplished using doctrinally correct 
Advanced Field Artillery Tactical Data System (AFATDS) message traffic and DIS protocol data 
units (PDU). 

The ETE test consists of four phases. Phase 1 develops or modifies the components that allow 
the mix of live and simulated targets at an E-8C operator’s console and ground station module 
(GSM) operator’s console. Phase 2 evaluates the utility of ADS to support DT&E and early 
OT«feE of a C4ISR system in a laboratory environment. Phase 3 transitions portions of the 
architecture to the E-8C and ensures the components function properly and the synthetic 
environment interacts with the aircraft and the actual GSM in a proper manner. Phase 4 
evaluates the ability to perform test and evaluation of the E-8C and GSM in a synthetically 
enhanced operational environment using typical operators. 
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2.0 Phase 1 Overview 
2.1 Phase 1 Purpose 


The purpose of Phase 1 is to develop, modify, and integrate software and hardware which will be 

used to establish the ETE test environment as well as plan and coordinate activities for Phases 2 
through 4. 


The ETE environment components developed during Phase 1 consist of a constructive simulation 
to provide virtual targets, an E-8C simulation called the Virtual Surveillance Target Attack Radar 
^ to allow surveillance and control data link (SCDL) traffic from 

VSTARS to be displayed in the GSM, and an ADS network suitable for integration and testing. 

2.2 Phase 1 Approach 


The J^S ETE team developed requirements for a constructive simulation and then evaluated 
available constructive simulations against these requirements. The Janus simulation developed 
Md managed by the U.S. Army Training and Doctrine Command (TRADOC) Analysis Center 
White Sands Missile Range (TRAC-WSMR), New Mexico, was selected as the simulation which 
had the best potential of being modified to meet IADS requirements. TRAC-WSMR expanded 
! scenano driver into Janus 6.88D, a constructive simulation capable of supporting up to 

10,000 individual entities with a distributed interactive simulation (DIS) interface to the ETE 
environment. 


The JADS ETE team investigated existing simulations of Joint STARS and determined that none 
u the fidelity requirements. Northrop Grumman, the developer of 

toe E-8C, performed the engineering and development of both a laboratory emulation of the 
subsystem and the capability to integrate the E-8C into a synthetic environment. The 
T^S IS a laboratory emulation of the E-8C radar subsystem and other aircraft components 
which can receive synthetic targets from a DIS network and provide the stimulus to display these 
t^gets on the Advanced Technology Work Station (ATWS) or on the ground station module 
The radar processor simulator and integrator (RPSI) and the air network interface unit (ANIU) 
are the portions of the VSTARS which are installed on the aircraft. 


challenging aspects of Phase 1 was developing a near real-time simulation of the 
E-8C synthetic aperture radar (SAR). JADS ETE, through the Advanced Research Projects 
Agency (A^A) War Breaker project, conducted a trade study of various existing simulations. 
We selected the XPATCHES simulation developed by Wright Laboratory (Dayton, Ohio) and 
Loral Defense Systems (Goodyear, Arizona) as being the best starting point for the E-8C SAR 
simulation. Lockheed Martin Tactical Data Systems, Goodyear, Arizona, developed a SAR 
simulation that emulates the Joint STARS SAR operation. This simulation system is referred to 
^ the Advanced Radar Imaging Emulation System (ARIES) and is operationally embedded into 
Northrop Grumman’s radar processor simulation and integrator RPSI. 
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The normal connection between the E-8C and its associated ground stations is through a line-of- 
sight data link called the surveillance control data link (SCDL). After considerable investigation, 
the JADS ETE team determined this link could not be easily transmitted via commercial 
communications lines. Based on discussions among the team, Northrop Grumman, and 
Motorola, we determined the best approach would be to develop interfaces which transferred the 
normal message traffic between the E-8C and GSM rather than attempting to transfer the SCDL 
messages directly. Northrop Grumman and Motorola developed an interface control document 
which defined this message traffic. Northrop Grumman included the capability in VSTARS to 
capture these messages and divert them to an Ethernet, and Motorola developed an interface unit 
between the GSM and an Ethernet. This interface unit links the Ethernet with the internal 1553 
databus of the GSM. Additionally, the interface unit simulates the operation of the ground data 
terminal forcing the GSM operator to perform the normal linking process prior to receiving the 
message traffic from VSTARS. 

Initially, network equipment installed in Phase 1 connected TRAC-WSMR with the JADS 
TCAC at Albuquerque, New Mexico, and then extended the network from the TCAC to the 
Northrop Grumman laboratory facilities at Melbourne, Florida. Late in Phase 1, this network 
was extended to include links from the TCAC to Fort Hood, Texas, and Fort Sill, Oklahoma, and 
a link between Northrop Grumman and Fort Hood. 

During Phase 1, the JADS team evaluated two logger capabilities for use during the ETE test. 
One of these was developed in support of Janus and the other is a product from the U.S. Army 
Simulation, Training, and Instrumentation Command. The primary concern was to evaluate or 
establish the ability to accurately log large numbers of protocol data units (PDUs) over several 
hours. Several shortcomings of both of these products led the JADS team to develop the JADS 
logger. The JADS team also developed a set of data reduction and analysis tools in support of 
the ETE test. 

2.3 Phase 1 Schedule 

The schedule for Phase 1 was driven by the availability of funding and by contracting delays. 
Due to funding constraints during fiscal year (FY) 95, the ETE test was limited to modification 
of Janus and to conducting architecture and engineering studies on the Joint STARS simulation. 
Initial contracting for the studies required eight months and actual development of the RPSI and 
ARIES did not begin until FY97. Figure 2 is the as built schedule for Phase 1. 
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Figure 2. Phase 1 Schedule 

2.4 Phase 1 Costs 

Table 1 outlines the costs for Phase 1. 

Table 1. Phase 1 Costs 


Element of Cost 

Cost 

Total 

Janus 6.88D 

$462,000 

$462,000 

Janus Hardware Suite (2) 


$80,000 

E-8C Simulation 


$2,617,560 

Architecture/Engineering Design 

$678,000 


Development/Integration 

$1,839,560 


Contracting Fee 

$100,000 


ARIES Development 


$864,450 

Development 

$832,830 


Contracting Fee 

$31,620 


SCDL Link Development 


$327,490 

Network Leases 


$90,312 

Network Equipment and Instrumentation 


$173,720 

Test Team Expenses 


$114,360 

Hardware/S oftware 

$21,040 


Travel 

$85,530 


Training 

$7,790 


Total Phase 1 Costs 


$4,729,892 
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3.0 Phase 1 Results 


3.1 Constraints, Concerns, and Methodologies When Using ADS 

One of the key constraints identified for JADS is the ability of the DoD infrastructure to support 
ADS test and evaluation. A measure of this constraint is found in the amount of development 
required to establish a synthetic environment with which to conduct testing. The ETE test 
provides insight into the amount of development required to support a test of this type and 
demonstrates the application of a systems engineering methodology to identify the requirements 
for ADS components, evaluate the availability of ADS components, and modify or develop the 
components to meet the requirements. 

3.1.1 Constructive Simulation - Janus 6.88D 

To generate the notional corps rear area, a constructive, entity-level simulation was required. 
The following represents the requirements developed to evaluate the capability of various 
existing simulations to support the JADS ETE. 

Requirements: 

• Capable of simulating, or of being modified to simulate, at least 5000 distinct entities with at 
least twenty-five percent moving in a reasonable and affordable manner. 

• Capable of issuing DIS 2.0.4 entity state (ES) PDUs that describe each entity simulated. 

• Capable of receiving and acting upon ESPDUs, fire PDUs, and detonation PDUs. 

• Capable of running for at least eight hours with human intervention as required. 

• Capable of running at or representing real-time actions. 

• Must use terrain data base at least 200 kilometers (km) by 200 km and based on National 
Imagery and Mapping Agency products. 

• Must have a V&V history, an accreditation history for analysis, be under configuration 
control, and be well documented. 

• Must reasonably represent entity movement, stopping, and turning. 

• Must represent the effects of a bombing or missile attack on the entities represented in an 
acceptable and credible manner. 

This analysis indicated that none of the constractive simulations would meet the ETE 
requirements without modification and development. JADS ETE identified the following criteria 
from the requirements for selecting which simulation to modify. 

1. Capable of producting large numbers (1000s) of “intelligent” (semiautomated, nonscripted, 
nontemplated, human controllable) interactive entities. 

2. Capable of conducting the simulation in a large terrain box (preferably at least 200 km by 200 
km) while operating at the entity level described in 1. 

3. Previously verified and validated (preferably by the Army) for combat development and 
OT/DT studies. 
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4. DIS compatible. 


Table 2 provides the comparison of the constructive simulations which led to the selection of the 
Janus simulation as the best candidate for upgrading to meet our requirements. 


Table 2. Constructive Simulation Comparison 


CRITERIA 

EAGLE 

CBS 

BBS 

JCM 

STAGE 

JANUS 

MODSAF 

1 

No 

No 

No 

No 

No 

Yes 

No 

2 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

3 

No 

No 

No 

No 

No 

Yes 

No 

4 

Yes 

No 

Yes 

^ No 

No 

F Yes 

Yes 


J^us IS under the configuration control of the U.S. Army Training and Doctrine Command 
(TRADOC) Analysis Command, White Sands Missile Range (TRAC-WSMR) and the Army 
Simulation, Training, and Instrumentation Command (STRICOM). IADS entered into an 

^ appropriate, to be able to represent at least 
5000 entities. The entity-level data generated by Janus will be converted into ESPDUs by an 
interface developed by TRAC-WSMR for that purpose. 

Janus is an interactive, computer-based simulation of combat operations conducted by platoons 
through brigades. The original Janus simulation began in the late 1970s at Lawrence Livermore 
National Laboratories to provide commanders interactive control of a combat simulation in the 
presence of nuclear effects. In 1983, TRAC-WSMR obtained Janus and enhanced Janus as a 
high-resolution simulation to support analysis for Army combat development. In 1991, 
TRADOC selected Janus for training at the company and platoon levels. Janus has also been 
used by the Command and General Staff College to train new battalion and brigade commanders 
on the principles of synchronized combined arms operations. 

Janus is a suite of programs with over 200,000 lines of FORTRAN code. These programs 
produce an envuonment that allows the user to set up the desired battle. Terrain, performance 
data, forces, unit symbols, and command and control overlays are typical entities that can be 

graphics programs such as the Janus analyst workstation 
(JAAWS) and the controller workstation add to the utility of the Janus user’s application tools. 

TRAC-WSMR has an ongoing program of enhancement and improvement of Janus JADS 
entered into an agreement with TRAC-WSMR and, with other programs, has sponsored various 
enhancements to Janus to allow it to meet ETE requirements. The result of these efforts is Janus 
6.88D. Janus 6.88D provides capabilities which include enhancements sponsored by JADS or 
other programs in the following areas. 

The number of units allowed in Janus was extended from 1200 to 6000, then to 8000, and most 
recently to 9999 in Janus 6.88D. Initial tests of even the first extension to 6000 units revealed 
that versions would not run real time. Further testing revealed the cause to be the updating of the 
unit locations on the graphic display. Major changes were required, and the solutions were 
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creative, based on solid computer science theory, and extremely useful. In order to reduce the 
graphic update time required, a process called heterogeneous aggregation (HA) was 
implemented. The interactor is able to dynamically select the level of detail of the units 
displayed on the graphic screen. A graphics interface was added to the Force editor that allows 
the user to build and modify a force according to military organizations with specification to the 
entity level possible at any level of aggregation. No phenomenology was changed for HA; the 
war fighting engine still operates at the entity level. Janus was modified to allow deployment 
and route building for organizations. The large numbers of units did require that some functions 
not directly related to HA be modified. Even more changes were made after observing users 
struggle with building large scenarios. Several modifications were made to reduce the labor of 
the user. The implementation of HA is of broad general use to all Janus users and has been a 
tremendous benefit to the U.S. Army. Of the many benefits of the JADS project, the addition of 
this capability to Janus is certainly a significant one. 

Prior to the JADS project, TRAC-WSMR used an external program called Janus Distributed 
Interactive Simulation (JanDIS) which ran on the same host and shared memory with Janus, the 
combat model program, to communicate with other systems on a network. Practical use in JADS 
and other distributed projects revealed that the arrangement was too hard to use. The DIS 
interface was integrated into Janus with a graphical interface for user control of runtime 
parameters. The firing and detonation PDUs were implemented and tested in the JADS network 
in coordination with the Tactical Army Fire Support Model (TAFSM). 

When Janus is used in a stand-alone exercise, the Janus analyst workstation (JAAWS) program is 
used as an after action review (AAR) tool. When Janus is part of a distributed application, 
information from entities not under control of Janus would not be available to JAAWS. Janus 
Plan View Display (JanPVD) was developed from the JAAWS pattern to display PDUs from all 
sources. JanPVD can run in the live mode displaying information in real time, or it can run from 
recorded data to provide replay capability. JanPVD displays position, losses, direct fires, indirect 
fires, and artillery impacts. The user can select from six different graphs of analysis measures 
over time. In the replay mode, the user has the additional capability to display movement and 
routes. 

3.1.2 Joint STARS Simulation - VSTARS 

The primary interface between the synthetic environment and the Joint STARS system is a 
simulation of the Joint STARS radar. The phasing of the program required two versions of the 
simulation, a laboratory version for Phases 1-2 and a version that could be installed on the 
aircraft for Phases 3-4. The requirements for the simulation are as follows. 

• Joint STARS simulation shall enable the mixing of MTI radar virtual entities, terrain, and 
SAR images in a seamless manner with the actual radar images produced by the E-8C while 
performing an operational mission. 

• Joint STARS simulation will operate within the timeline standards, utilize the same system 
parameters, and use the same message formats established for the Joint STARS radar system. 
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• When installed on the E-8C, Joint STARS simulation will provide simulated radar data 
integrated with live radar data when operating within the ETE synthetic environment. 

• For MTI radar reports. Joint STARS simulation will allow operation in three modes: live, 
where all data are provided by the radar operating system; mixed, where both live and virtual 
data are provided; and virtual, where all data are provided by the synthetic environment and 
the Joint STARS simulation. SAR reports will be either real or virtual with no mixing. 

In^l modes of operation. Joint STARS simulation will permit all of the normal operations 
performed by the console operator to remain possible, such as target tracking, target type 
identification, etc., even though most or all of the targets are virtual entities. 

When working on a Joint STARS simulation supplemented workstation, the operator should not 
be able to easily distinguish between live and virtual targets, either visually or as a result of any 
action normally taken in the course of performing duties. 

The ETE team surveyed existing simulations of the Joint STARS radar modes with the following 
results. ^ 


Radar Modes 


• None of the existing simulations of the moving target indicator (MTI) mode of the Joint 
STARS radar duplicated the actual radar characteristics. 

• There were no simulations of the synthetic aperture radar (SAR) mode of the Joint STARS 

radar. The best existing simulation provided a limited number of canned images bearing no 
operational relevance to the scenario. 


• The lack of a SAR simulation precluded support of the fixed target indicator (FTD mode of 
the Joint STARS radar. 

System Representation 

• The existing simulations were either E-8C workstation simulations or ground station module 
stimulators. 


• The existing simulations provided no intersystem interaction and therefore were not designed 
to operate with actual E-8C components. 

• The existing simulations did not provide all the operator functionality. 
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Intersystem Timelines 


• The existing simulations used fixed estimates of the intersystem timelines and therefore were 
not driven by loading on the system. 

Due to the lack of any existing simulation to meet the requirements, JADS initially contracted 
with Northrop Grumman to evaluate system architectures and develop an engineering design of 
the selected architecture. The architectural smdy recognized the primary challenge for the Joint 
STARS simulation was its integration on the aircraft. Therefore, the study evaluated three 
candidate architectures for the aircraft version of the simulation. 

• Minimize the message traffic on the hardware busses and contain the simulation on the same 
processing unit as the existing MTI processing. 

• Minimize the impact on existing processing by isolating the simulation in an independent 
processor. 

• Increase the fidelity of the simulation or lower the level at which the simulation will be 
performed. 

Each of the three architectures was designed to the level required to evaluate them against the 
following criterion: 

Timeline Impact 
Memory Requirements 
System Loading 

Modification of Existing Software 
Modification or Addition of Hardware 
Use of Existing Simulations and Models 
Level of Simulation 
Integration Complexity 
Expandibility/Growth 

The first candidate was found to have minimal direct impact to the timeline, however, the radar 
data processor would have increased load and would impact the existing MTI processing. The 
integration complexity of this architecture was considered large, and the architecture did not 
support expansion without impacting existing processing. 

The second candidate was found to have no impact on the timeline, memory or system loading. 
This candidate required a reconfiguration of the system configuration to use the spare general 
purpose computer (GPC). Integration complexity was reduced, and the architecture could be 
expanded to the maximum capability of the GPC. 

The third candidate was expected to impact the timeline as a function of target load. This 
candidate required the largest development. While the first two candidates limited the level of 
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the simulation to the MTI report, this architecture would include all sections of the MTI 
processing up to the signal processor. Integration was considered equivalent to candidate 2. 
While the expandibility of this candidate was only limited by the capacity of the GPC, the 
limitation on the number of targets limited the growth of this architecture. 


The resulting reconunendation was to adopt the second architecmre for JADS requirements. 
Candidate 3 was identified as a future possibility for implementation because of the expanded 
testing capabilities. Appendix A, Architectural Design Report for the Radar Processor 
Simulation for the Joint Surveillance Target Attack Radar System (Joint STARS), is the resulting 
report for this study. ^ 

Following the selection of the appropriate architecture, Northrop Grumman conducted an 
engineering design of the radar processor simulation and prepared a specification of the system- 
level requirements for the radar processor simulation. Appendix B, Engineering Design Report 
or the Radar Processor Simulation for the Joint Surveillance Target Attack Radar System (Joint 
STARS), documents the hardware and software requirements for the radar processor simulation. 

During the joint feasibility study (JFS) phase of the JADS JT&E, the ETE team identified the 
lack of a SAR simulation for the Joint STARS radar to be one of the key risk areas for the ETE 
test, bi parallel with the JFS, the Advanced Research Projects Agency conducted a trade study of 
13 existing SAR simulation capabilities in support of the War Breaker program. The War 
Breaker requirements were similar to the JADS requirements, and the ETE program entered into 
an agreement with the War Breaker to cooperate on the development of the SAR simulation As 
a result of the trade study, the War Breaker identified two candidates as having the potential to be 
used as a baseline for the development of a SAR simulation. These vendors were requested to 
submit a rough order of magnitude estimate for the development, and Loral Defense Systems 
Goodyear, ^izona, was requested to submit a proposal for a Radar Image Simulation System 
(RKS) to be based on the XPATCHES simulation developed under sponsorship of Wright 
Laboratory. The RISS was conceived as a generic SAR simulation which would be capable of 
simulating SAR capabilities of Joint STARS, Tier n+/ni Unmanned Aeriel Vehicles and the U- 
2R platforms. During contractual negotiations, the War Breaker program was canceled and 
L^S ETE was left without a partner for the SAR simulation development. In cooperation with 
Wnght Laboratory, JADS contracted with Lockheed Martin Tactical Defense Systems, the 
successor of Loral, to develop a Joint STARS specific SAR simulation. This system is called the 
Advanced Radar Imaging Emulation System (ARIES). 

In 1996, JADS ETE, in cooperation with Rome Laboratory, contracted with Northrop Grumman 
to develop a Joint STARS E-8C simulation, consisting of a radar processor simulator and 
integrator (RPSI), a distributed interactive simulation network interface unit (DIS NIU) and a 
data link databus interface unit. This simulation would be developed in accordance with 

architecture candidate 2 and would be capable of integrating a SAR simulation developed under 
another contract. 

The resulting Joint STARS E-8C simulation is called the Virtual Surveillance Target Attack 
Radar System (VSTARS), an emulation that represents the radar subsystem of the Joint STARS 
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E-8C in a laboratory environment. It is composed of the DIS NIU, the RPSI that contains the 
two real-time radar simulations with necessary databases, and various simulations of E-8C 
processes. 



CDP - central data processor SM&C - system management and control 

M&IS - management and integration software SMO - system management officer 


Figure 3. VSTARS Architecture 

The DIS NIU functions are divided between two components. The ground NIU is connected to 
the DIS network and receives entity state protocol data units (ESPDUs) from the network. It also 
performs coordinate conversion to the radar’s coordinate system and reduces the ESPDUs from 
the standard 1152 bits to 192 bits. (See Appendix C.) This reduced data packet is then sent to 
the air NIU where dead reckoning is performed. The splitting of the NIU is required because the 
RPSI will be integrated into an actual E-8C allowing the mix of live and virtual targets onboard 
the aircraft. The ESPDU is reduced in size, and dead reckoning is performed by the air NIU in 
order to reduce bandwidth requirements for the link between the two NIUs. 

The RPSI completes the concept for mixing real and virtual radar returns. It mixes virtual MTI 
returns on virtual terrain, and virtual SAR images with actual radar returns without causing any 
degradation of the aircraft system’s capability for handling actual (live) targets. The RPSI is 
based on the architecture of the aircraft radar subsystem and functions within the actual radar 
processor software. It is triggered by the same message structures currently used to communicate 
with and within the radar subsystem; nominally works within the radar subsystem timelines; and 
outputs its reports in the same formats currently used by the radar subsystem. 
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When integrated into the radar subsystem of the E-8C, the RPSI architecture is designed to 
function in three primary modes. 

1. All real, where only the aircraft’s radar subsystem is providing information on the real 
environment. 

2. Mixed mode, where both the radar subsystem and the RPSI are providing information on the 
real and virtual environment. 

3. Virtual mode, where only the RPSI is providing information on the virtual environment. 

The MTI simulation developed by Northrop Grumman and used in VSTARS is based upon an 
engineering model used during the development of the E-8C radar. As such, it went through 
many cycles of model-test-model and is considered to be a valid model of the MTI mode of the 
E-8C radar. It characterizes target probability of detection (Pd) and location accuracy, in the 
presence of clutter assuming a constant false alarm rate, as a function of key radar system 

variables that can be implemented in the real-time target detection stream of the MTI radar 
system. 

The simulation receives programmable signal processor (PSP) messages that indicate the limits 
of the current radar beam footprint (dwell quadrilateral) and determines what portion of the 
footprint IS allowed virtual targets. It then determines which moving virtual targets are located 
within the virtual portion of the dwell quadrilateral, based upon their latest dead reckoned 
position. Once the possible target set is determined, Pd is applied and the detected target set is 
derived. Location error is then applied to the detected targets and the target set is sent to the 
radar post processor. A false alarm simulation runs whenever the MTI simulation is operating in 
the ‘virtual only’ mode. This generates false returns, including meteorological effects based 
upon radar system variables. A flow diagram for the MTI simulation is shown in Figure 4.’ 
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I&Q - in-phase and quadrature (radar data) VDPS - VSTARS data packet 


Figure 4. VSTARS MTI Flow Diagram 

The SAR simulation, ARIES extends the capabilities of XPATCH target signature modeling, 
XPATCHES image scene generation, and interfaces with Northrop Grumman’s RPSI to provide 
a complete methodology for the real-time simulation of the Joint STARS SAR mode of 
operation. 

ARIES will be initiated by the receipt of a radar service request requesting a SAR image with an 
image center point specified within the virtual portion of the ground radar coverage area 
(GRCA). The GRCA covers thousands of square kilometers, is specified in the mission orders, 
and is the area scanned continuously by MTI wide area surveillance. It also acts as a limiting 
area for special radar products such as a SAR image. The virtual portion of the GRCA will be so 
indicated upon initialization of the RPSI. ARIES, upon initialization of the RPSI, will create 
three data bases within hardware random access memory (RAM) containing elevation and feature 
data for the GRCA, and a feature target function library for all the features contained in the 
feature data base. 

Once the center point of the virtual SAR image is known, ARIES will over sample around the 
center point and extract the elevation data for an area that will exceed the image area coverage. 
ARIES determines from the contour algorithms if any terrain feature outside the image area will 
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influence the image area. ARIES will also determine which terrain features exist within the 
target area. Using this data, ARIES will develop a ground truth point map of the sampled area. 

ARIES will wait for the PSP parameter message to arrive before doing any further processing. 
The PSP parameter message, a product of the actual scanning of the area of interest (AOI) by the 
radar, contains such information as actual grazing and squint angles, size of imaged area and 
other information needed by ARIES to image the AOI. Once the PSP parameter message is 
received, ARIES will select the actual image area from the ground truth point map and begin 

applying XPATCHES image generation algorithms to generate the SAR scene. The SAR flow 
diagram is shown in Figure 5. 



^ Rad ar Service Request 
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Figure 5. VSTARS SAR Flow Diagram 

The RPSI will also receive the PSP parameter message and will use the actual imaged area to 
determine what virtual targets are located within the AOI. It will then send this target list to 
ARIES, which will obtain from feature target function libraries the appropriate target image chips 
for insertion into the SAR image. Moving targets will be displaced, or smeared, within the 
image as appropriate. Once this is accomplished, the image will be sent to the RPSI for 
forwarding to the post processor. Timing studies indicate that it will take ARIES up to three 
times longer, depending on the processor, to generate a SAR image than the real radar. Since the 
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requester has no way of knowing when the SAR mission was initiated, we do not feel that this 
delay will be noticed. 

Both the MTI and SAR simulations allow the radar operators to perform all of their required 
functions. 

The primary difference between VSTARS operating within the laboratory and the RPSI operating 
on board the real E-8C is the need to simulate the navigation subsystem and certain radar 
components within the laboratory. These simulations make it possible for VSTARS to function 
without an E-8C present. 

In use, VSTARS must be connected to an operator’s workstation, currently the Advanced 
Technology Work Station, that serves as the interface between the aircraft crew and the radar. 
VSTARS output can also be sent to the ground component of Joint STARS via a virtual 
surveillance control data link (SCDL). 

Appendices 4 and 5 document the Phase 1 efforts of Northrop Grumman and Lockheed Martin 
respectively. 

3.1.3 Surveillance Control Data Link Interface 

Joint STARS consists of two segments: the air segment consisting of the E-8C and the ground 
segment consisting of a ground station module (GSM) or a common ground station (CGS). 
These segments are connected via a line-of-sight radio frequency data link called the surveillance 
control data link. This data link supports the transfer of radar products from the E-8C to the 
GSM/CGS and allows the GSM/CGS operators to submit radar service requests to the E-8C. 
Additionally, the data link supports free text messaging between the E-8C and the GSM/CGS. 

The initial concept for connecting the VSTARS and the GSM/CGS was to encapsulate the SCDL 
messages in a DIS message PDU. Upon more detailed research the ETE team discovered the 
necessary data concerning the SCDL were not releasable, and that the team would be unable to 
encapsulate the data. The next approach was to transmit the SCDL directly over a wide area 
network link. In this case, the team discovered they were unable to make the intrusive link into 
the ground data terminal (GDT) of the GSM/CGS. The final solution for making this connection 
was to capture the data prior to their transformation into SCDL data and transmit these data 
between VSTARS and the GSM/CGS. In VSTARS this entailed capturing the data prior to the 
SCDL process, and in the GSM/CGS the data are bridged from a local area network connection 
to the military standard (MIL-STD) 1553 databus in the GSM/CGS. 

The VSTARS data link databus interface unit consists of a software process within VSTARS that 
establishes a connection between VSTARS and the GDT 1553 bus interface unit (BIU) at the 
GSM/CGS. This connection uses the transmission control protocol to establish a reliable 
communications link via a local area network connected to the VSTARS processor, a secure 
wide area network link, and the local area network connected to the GDT 1553 BIU. 
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The interface between the VSTARS data link databus interface unit and the GDT 1553 BIU is 
controlled by an interface control document between Northrop Grumman and Motorola 
Communications System Division. (Appendix F) 

The GDT 1553 BIU was developed by Motorola Communications Systems Division, Scottsdale, 
Anzona. Motorola is also the developer and producer of both the GSM and the CGS. The GDT 
1553 BIU consists of a Sun SPARC 5 workstation with both Ethernet and MIL-STD 1553 
interface cards. The BIU is integrated with the GSM/CGS is such a way that the GSM/CGS 
operator must establish a SCDL using the normal operational procedures and commands before 
the BIU will allow the connection via the wide area network. 

Appendix G is the software test plan for the GDT 1553 BIU. JADS ETE established a 
communications link with Northrop Grumman in Melbome, Horida, to support integration 
among the contractors and testing. The initial test was conducted at the Motorola facility in July 
1997 between prototype CGSs and VSTARS. In this test, a data dropout problem was identified 
which could not be isolated. The decision was made to accept the BIU pending its integration 
with an operational GSM at Fort Hood, Texas. In February 1998, the GDT 1553 BIU was 
integrated with two light ground station modules at Fort Hood. The test was successfully 
repeated dunng this integration period. We believe the combination of controlling the speed of 
the data link, a normal function with the actual SCDL, coupled with a stable test environment of 
operational GSMs, rather than prototype CGSs, solved this integration problem. 

3.2 End-to<End Network 

The ETE network was designed to be a dedicated network based on commercial communications 
links using DIS protocols where appropriate. The ETE team developed an engineering process 
for identifying the requirements for any network configuration considered. As the makeup of the 
ETE synthetic environment evolved during the planning stages of Phase 1, the ETE team used 
this process to refine the requirements for the ETE network. We will describe this process in 
terms of the network integrated at the end of Phase 1. 

3.2.1 Network Requirements Analysis 

The first step in the process is to conduct a flow analysis of the data required. Each node is 
examined to identify the data required from other nodes and the data supplied to other nodes 
Figure 6 is ETE data flow diagram. 

fo addition to the PDU and data link data identified in the diagram, each site is connected with a 
dedicated voice link for test control. 
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Figure 6. EXE Data Flow Diagram 

The second step in the process is to estimate the amount of data required to pass between the 
nodes. For example, the estimate for the entity state PDUs from WSMR to the TCAC is made 
using the following calculation: 

Assumptions: 9500 entities publishing ESPDUs with a heartbeat of 1 minute 
No more than 25% of the entities moving during any second 
No more than 1% of the moving entities changing state during any second 
ESPDU consists of 1152 bits 
PDU protocol overhead is 288 bits 

Heartbeat Requirement: 9500 entities / 60 seconds = 158.3 PDUs per second 
State Change Requirement: 9500 entities X .25 = 2375 movers 

2375 movers X .01 = 23.75 PDUs per second 

Total ESPDUs per second: 183 per second 

Total bandwidth required: 183 PDUs per second X 1440 bits = 263,520 bits per second 
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Each flow between two nodes is estimated using similar calculations and the total flow between 
the two nodes is calculated. Additionally, network management overhead is estimated and added 

to the total. The resulting estimated requirement for the WSMR - TCAC example is calculated 
below: 

ESPDUs from WSMR 
ESPDUs to WSMR 
Fire PDUs to WSMR 
Detonate PDUs to WSMR 
Voice Channel 
Network Management 
Total Requirement 
Safety Factor (X 2) 

The final step in the process is to determine the appropriate size of the commercial link between 
the nodes. In general, commercial links are sold as channels each having a 64,000 bps capacity 
and T earners consisting of multiple channels, e.g., a T-1 link having 24 channels (1 544 
megabits per second). The example above would require 11 channels or a single T-1 link. 

The ETE team performed numerous estimates of the network requirements based on varying 
assumptions and configurations. Based on these various estimates, the requirements for the ETE 
network showed above were as follows: 


^ ^ 1 *544 Mbps (megabits per second) 

'T'l 1.544 Mbps 

2 channels .128 Mbps 

4 channels .256 Mbps 

4 channels .256 Mbps 

^though the estimated requirements for three of the links were less than T-1 capacity, we 
determined during procurement that commercial vendors charged less for T-1 links than for 
fractional T-1 links. Therefore, all the links for the ETE network are T-1. 

3.2.2 End-to-End Network Security 


WSMR-TCAC 

TCAC - Northrop Grumman 

TCAC - Fort Hood 

TCAC - Fort Sill 

Northrop Grumman - Fort Hood 


263,520 bps (bits per second) 
2,880 bps 
768 bps 
832 bps 
64,000 bps 
500 bps 
332,500 bps 
665,000 bps 


Security presented a problem for the ETE network. The initial concept for the ETE network was 
for an encrypted network protected at the secret level. As the team coordinated the requirements 
with the vanous nodes, we determined that supporting a classified network presented problems 
tor three of the nodes. The Northrop Grumman node was the node which required protection and 
My connection to this node would also require protection. Through analysis of the data flows 
determined that the only data flowing from Northrop Grumman was a single 
bSPDU per second which would only be used for test control. Therefore, we determined that if 
we could establish a security guard or an air gap between the sites desiring to operate at the 
unclassified level and the TCAC, Northrop Grumman, and the GSM, we could overcome the 
problems at these sites. Figure 7 describes the resulting network. 
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CAMPS - Compartmented All Source Analysis System Message Processing System 

Figure 7. EXE Network 


TAG - target analysis cell 


The initial separation between the unclassified segment and the classified segment was effected 
by developing an unclassified annex of the TCAC and connecting it with a low to high security 
guard consisting of a simplex encrypted link. This link allows traffic from the unclassified 
segment to be passed to the classified segment, but blocks traffic from the classified segment 
from flowing to the unclassified segment. The other break occurs at Fort Hood. The 
Compartmented ASAS Message Processing System (CAMPS) is a configuration of the All 
Source Analysis System (ASAS) which is certified as a high to low security guard. This system 
is being used in the ETE network to separate the secret-level GSM from the unclassified segment 
of the network. 


3.2.3 End*to-End Network Characterization 


The JADS JTF identified network technology as a potential concern or constraint for using ADS 
for test and evaluation. The JADS evaluation methodology identifies several measures used to 
evaluate the network related concerns and constraints. The following measures were evaluated in 
part or in whole in Phase 1. 
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M 2-1-2-3 Average and peak bandwidth used by link. 

M 2-1-2-6 Percentage of total PDUs required at a node that were delivered to that node. 

M 2-1 -2-7 Average and peak data latencies between ADS nodes. 

The JADS Network and Engineering and Analysis teams in conjunction with the ETE team 
developed a process for characterization of a network link prior to its integration into a synthetic 
environment. At Appendix H are the results of characterization tests conducted by Northrop 
Grumman, WSMR, Fort Hood, and Fort Sill links, respectively. An instrumentation limitation 
exists m JADS ability to measure average and peak bandwidth for all the ETE links. The 
particular instrumentation suite used to measure bandwidth utilization is called SPECTRUM. 
This instrumentation suite is installed in the classified portion of the TCAC and is currently 
classifi^ secret. Therefore, we cannot use it to measure bandwidth utilization for unclassified 
links. This limitation is reflected in the data reported below and in the appendices The tables 
below summarize the results of these tests. 


Table 3. Bandwidth Utilization for Grumman Link 


Times 

Expected Rate 
(X E.R.) 

Rate (PDU/sec) 

Number PDUs 
Received 

Bandwidth 
Utilization (%) 

1 X E.R. 

100 

11859 

10 

2 X E.R. 

200 

11858 

21 

3 X E.R. 

300 

11853 

28 

4XE.R. 

400 

' 11847 

40 

5 X E.R. 

500 

10492 

45 


Table 4. PDU Verification Test Results 


Location 

No. of PDUs 
Received 

No. of PDUs 
Transmitted 

No. of PDUs 
Out of Order 

No. of PDUs 
> 1 sec. 

Grumman 

11859 

11859 



WSMR 

11859 




Fort Hood 

11859 


0 


Fort Sill 

11859 


0 
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Table 5. Stress Test Results (11859 PDUs Transmitted) 


Link 

Times Expected Rate 
(XE.R.) 

Rate (PDU/sec) 

Ping Time (ms) 
Min/Max/Ave 

Number PDUs 
Received 

Grumman 

1 X E.R. 

100 

60/120/61 

11859 


2XE.R. 

200 

59/90/68 

11858 


3 X E.R. 

300 

59/90/64 

11853 


4 X E.R. 

400 

57/210/79 

11847 


5 X E.R. 

500 

57/840/256 

10492 

WSMR 

1 XE.R. 

100 

59/61/59 

11859 


2XE.R. 

200 

41/61/59 

11858 


3 X E.R. 

300 

41/60/45 

11853 


4 X E.R. 

400 

41/61/58 

11850 


5 X E.R. 

500 

41/70/56 

11849 

Fort Hood 

1 X E.R. 

100 

40/69/59 

11859 


r 2 X E.R. 

200 

37/60/42 

11858 


3 X E.R. 

300 

r 50/60/59 

11853 


4 X E.R. 

400 

38/61/58 

11859 


5 X E.R. 

500 

37/61/54 

11859 

Fort Sill 

1 X E.R. 

100 

30/61/58 

11859 


2 X E.R. 

200 

30/60/52 

11857 


3XE.R. 

300 

30/61/43 

11853 


4XE.R. 

400 

30/60/36 

11859 


5 X E.R. 

500 

30/84/300 

10656 


Table 6. No Load Latency Test Results 


Source 

Destination 

No. Packets 

Round-Trip Time (ms) | 

Minimum 

Maximum 




32 

57 

71 

57 


WSMR Indy 

32 

41 

44 

41 



32 

37 

77 

38 


Indy 

32 

30 

40 

30 
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Table 7. Loaded Latency Test Results 


Source 

Destination 

Packet 

Rate(sec) 

Packets 

Sent/Rec 

Round-Trip Time (ms) I 

Min 

Max 

Aye 

TCACJndy 

Grummanjndy 

.01 

320/320 

58 

163 

60 



.005 

640/639 

58 

61 

58 



.0025 

1280/1279 

58 

124 

58 



.00125 

2560/2559 

58 

167 

58 

TCAC.Indy 

WSMR Indy 

.01 

320/320 

42 

45 

42 



.005 

640/639 

42 

85 

42 



.0025 

960/960 

42 

51 

42 

TCACJndy 

Fort Hood Indy 

.01 

320/320 

38 

39 

38 



.005 

640/639 

39 

55 

39 



.0025 

960/960 

38 

76 

39 

TCAC_Indy 

Indy 

.01 

320/320 

31 

33 

31 



.005 

640/639 

31 

33 

31 



.0025 

960/960 

31 

33 

31 


The results of the network characterization tests indicate the ETE network should meet the 
performance requirements of the tests with adequate margin. 

The stress test results indicated a potential problem with loss of data under stressful situations. 
Appendix I documents a detailed analysis of this problem performed by the JADS Network and 
Engineering team and a field engineer from Network Equipment Technologies, the developer and 
manufacturer of one of the routers used by JADS in their networks. 

The local area network (LAN)/wide area network (WAN) Exchange (LWX)/Cisco router 
investigation had five objectives: 

1. Venficahon/validation of the problems witnessed by JADS Network and Engineering 

2. Comparison of the performance gains/losses of external router configurations 

3. Effects of altering internal software configuration (buffers, hold queues, etc.) 

4. Effects of using a hybrid routed/bridged network 

5. Effects of a completely bridged network 

The LANAVAN Exchange (LWX) Release 3.01 is a general purpose router/bridge integrated into 
the Integrated Digital Network Exchange (IDNX) platform. It provides internetwork connectivity 
between LANs over WANs through IDNX/ 90, /70, /20, and /Micro 20 IDNX nodes The LWX 
is the pnmary router used in the ETE network. The investigation also evaluated the performance 

of two versions of routers from Cisco. All the routers evaluated use equivalent software from 
Cisco. 
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Throughout all the tests the broadcaster, a Silicon Graphics, Inc. (SGI) Indy workstation, used a 
file that consisted of 11,859 DIS ESPDUs. The SGI workstation broadcasted the PDUs on its 
LAN as user datagram protocol (UDP) packets. The LWXs were configured to forward these 
broadcasts through the network. Each entity state PDU was 144 bytes in length. The internet 
protocol (IP) datagram produced was 152 bytes in length. All this was verified using a network 
general sniffer protocol analyzer on the Broadcaster subnetwork. 

At the distant end, the logger, also an SGI Indy workstation, listened for UDP broadcasts and 
counted the number received. The difference is the number of packets dropped within the 
network. 

The primary results of the investigation are as follows: 

• The use of UDP - an inherently unreliable transport mechanism - is not always a suitable 
choice of transport for data that needs a high level of reliability. The transmission control 
protocol (TCP) is better suited for reliable transport since it uses seijuencing and 
acknowledgments, but at a cost of increased latency - which was not tested. Also, the use of 
multicasting or unicasting would take advantage of the fast switching capability of all the 
routers tested. 

• The use of broadcast-based networking has an adverse effect on the network. Routing this 
traffic adds one additional layer of processing (especially when the broadcasts are process 
switched) and creates multiple copies of each datagram in order to forward it to multiple 
network subnets, thus, congesting the network with broadcast traffic. When routing 
broadcast traffic, the network should be designed as flat as possible. 

• There were definitive “break points” where the processors could not handle anymore packets. 
This was true on every platform tested. 

• During the testing, we did notice that there were drops on the hold queue, missed buffer 
requests, and fallbacks on the interface buffers. To remedy this we added to the hold queue 
length and increased the number of permanent big buffers. The actual number of successful 
packets sent never rose above the initial ceiling. In other words, the addition of buffers and 
increasing the hold queue did not affect, in any way, the speed at which the processor process 
switched the packets. 

• It is our best judgment that the limitation is with the router’s processor handling UDP 
broadcasts. With UDP broadcast traffic, all packets are process switched. With unicast and 
multicast traffic, the router is capable of fast switching most of the packets. Routers gain 
efficiencies when they are capable of caching routes for packets. 

The investigation concluded that with our current network configuration using routing between 
subnets, we were limited to an aggregate of 400 packets per second through any of the routers. 
This limitation is adequate for the planned ETE tests. If further studies identify the requirement 
for an aggregate throughput in excess of 400 packets per second, switching from routing to 
bridging between the subnetworks would allow up to 800 packets per second. 
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3.3 Data Management and Data Analysis 

Another potential concern or constraint for using ADS for test and evaluation is the impact of 
ADS on data management and data reduction. In addition to system under test data, an ADS 
implementation must instrument the synthetic environment to collect data on the environment 
^d analyze these data to determine the impact of the ADS environment on the system under test. 
The JADS evaluation methodology identifies several measures used to evaluate the data 
management and analysis related concerns and constraints. 

M 2-2-1-1 Degree to which ADS nodes provide for collection, data entry, and quality checking 
of pre-and post-trial briefing data. i ^ e 

M 2-2-1-2 Adequacy of relevant test data storage at ADS nodes. 

Subobjective 2-3-3 Develop and access methodologies associated with data management and 
analysis for tests using ADS. 


3.3.1 Synthetic Environment Data Collection 

The pnmapr instrumentation of the ETE synthetic environment are data loggers at each node to 
CO ect and time starnp all PDU data transmitted and received at the node. The ETE team 
planned to install dedicated data loggers at each location to ensure common data formats and file 
ormats for each site. Early in the JADS program, the planned approach for all tests using DIS 
was to use a logger application available from the U.S. Army Simulation, Training and 
Instrumentation Command (STRICOM). The testing of a C4ISR system such as Joint STARS 
required running operational scenarios over long periods of time, resulting in large 
(approximately 600,000 PDUs) data sets. ^ 


A limitation of the STRICOM logger was discovered during a line test between TRAC-WSMR 

capacity the STRICOM logger closes the file and ceases recording information. A proposed 
solution to the 256 segment limitation was the use of sequential files. The logger would 
recognize when a file was meeting the limitation, close the file and open a new sequential file. 
However, there existed the possibility that information might be lost during the process of 
closing one file and then opening a sequential file. An alternative to the STRICOM logger was 
the Janus logger, an application distributed with Janus that allowed the collection and replay of 
PDUs. However, the Janus logger was designed to time stamp to a one second accuracy. 

The ETE teani decided to develop a logger test to examine the strengths, weaknesses, and 
limitations of the STRICOM and Janus loggers. This test focused on two issues: 


1. What is the impact of using sequential files? 

2. Is the time stamping of the Janus logger sufficiently accurate for analysis? 

A test bed was established in the TCAC consisting of an Janus system providing the source of 
the PDUs, a Janus logger, a STRICOM logger set to a 50 segment limitation, and a STRICOM 
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logger set to a 250 segment limitation. The scenario was set to produce approximately 600,000 
PDUs over a two-hour test. 

The conclusions from this test are as follows: 

STRICOM Logger: Segmentation at either 50 or 250 segment size is usable. The opening and 
closing of sequential files did not disrupt the recording of PDUs. The file sizes should be chosen 
to enhance data sampling and analysis. The test uncovered a potential problem with the 
STRICOM logger. During one of the runs, one of the STRICOM loggers experienced a loss of 
151 PDUs in a single block. Although we were unable to identify the specific source of the loss, 
we suspected that some other process commenced which placed a demand on the processor 
resulting in the loss of the PDUs. 

Janus Logger: The Janus logger does not time stamp at the required accuracy to allow analysis of 
PDU latency and is therefore only useful for its playback capabilities. 

The conclusions of the logger evaluations led JADS to develop the JADS logger. The JADS 
logger was designed with three objectives: 

1. High degree of time stamp accuracy. 

2. Minimized processor load. 

3. Flexible playback capability 

The JADS logger was designed as two processes. The first process is a high-priority process that 
time stamps the PDU upon receipt. The second, a low-priority process, logs the PDUs when the 
processor is not busy. This ensures an accurate time stamp. The JADS logger provides users 
with a very high degree of accuracy with respect to log time (received time) of PDUs (typically 
better than 1 millisecond). 

The JADS logger foregoes graphics interfaces to minimize process load. It uses a simple 
command line interface, and in real time, displays the number of PDUs received and the PDU 
rate each time it writes a block of PDUs (typically about 500 entity state PDUs) to disk. 
Because the logger has a command line interface, the user can remotely log in (rlogin), start the 
logger as a background process and log out of the workstation without terminating the logger 
application. This option keeps network traffic to a minimum while performing the logging 
function at a remote location. 

JADS also developed the JADS player, a playback capability that operates in two modes: a 
speed mode where the operator identifies a multiplier to control the speed of the playback, and a 
rate mode where the operator designates the numbers of PDUs per second to be played. 
Additionally, in conjunction with the JADS analysis toolbox, the player can be directed to start 
the playback at any log time. 

The JADS logger/player meets all the requirements of the ETE test and provides a simple and 
reliable data collection and data analysis tool. 
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3.3.2 Synthetic Environment Data Analysis 

In addition to the logger tools, JADS developed various analysis tools for analysis of the PDU 
data. The tools have been integrated into (can all be called up from) a single tool, the JADS 
analysis toolbox. The toolbox provides users with a single interface to the softwie routines 
developed by JADS. These tools provide for real-time viewing of PDU data, and for post-test 
quick-look analyses using logged PDU 

The JADS analysis toolbox provides a point and click interface to the various JADS analysis 
routines. The routines available from the toolbox menu are the following: 

• Monitor - 3-D Display: A graphical 3-dimensional (3-D) display of up to 3 entities that 
displays latitude, longitude, and altitude in real time is provided. 

• Monitor - PDU Statistics and/or PDU Latency: The following PDU statistics are provided by 
the PDU statistics display: 

the total number of PDUs received, 
the PDU (receive) rate, 
the number of entities received, and 
the number of each type of PDU received. 

A plot of PDU latency (received time - PDU creation time) in real time is also available. 

Analyze - Quick-Look: The JADS quick-look analysis tool provides analysts with a point 
Md click means of obtaining mission, PDU, and logger performance data visualizations for 
DIS exercises. Visualization is provided for four categories of data: 

• Mission Visualization: Present support is for 3-D plots of up to 3 entities, e.g., a shooter, 

target, and missile, for either the total mission or just during the flyout, and either static or 
animated. 

• Latency Data Visualization: Plots of PDU latency {from PDU creation to time received}, 
from logger to logger, for all entities as well as for individual entities can be created. 
Aso, a latency statistics tabulation is available that enumerates the minimum, maximum 
and average latency for each entity, each test, and each logger. 

• PDU Performance Visualization: Plots of the number of PDUs received per second of 
PDU time and the number of PDUs per second of log time for each entity as well as for 
individual entities are created. Also, a PDU statistics tabulation is available that 
enumerates the number of PDUs, the number of duplicate PDUs, and the number of PDU 
dropouts, for each entity, each test, and each logger. 

• Logger Performance Visualization: Plots of log time difference between successive 
received PDUs for each entity as well as for individual entities are created. 


The quick-look analysis tool allows the user to select multiple sets of trials, loggers and 
entities and then sequentially presents the selected plot data for review, formatting, and/or 
printing. Thus, a summary analysis package can be prepared in a short time. The quick-look 
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analysis tool is used in conjunction with the JADS logger which records (logs) DIS PDUs 
during an exercise. 


• Analyze - General Plots: The JADS general plots tool provides for generalized plotting of 
data from a file. Plots of any of the supported PDU parameters (Entity ID [identification], 
Log Time, PDU Time, Latitude, Longitude, or Altitude versus another) may be made. 

• Dump - Select Entity Parameters: Dumps any to the following selected parameters into a text 
file from a log file: 

Entity ID 

PDU Time (milliseconds) 

PDU Timestamp (milliseconds - using all 32 bits with each bit as one millisecond) 
Latitude (degree) 

Longitude (degree) 

Altitude (feet) 

North Velocity (feet/second 
East Velocity (feet/second) 

Down Velocity (feet/second) 

X (meters, geocentric) 

Y (meters, geocentric) 

Z (meters, geocentric) 

X Velocity (meter/second) 

Y Velocity (meter/second) 

Z Velocity (meter/second) 

X Acceleration (meter/second/second) 

Y Acceleration (meter/second/second) 

Z Acceleration (meter/second/second) 

Phi (radians) 

Psi (radians) 

Theta (radians) 

Pitch (radians) 

Roll (radians) 

Yaw (radians) 

Pitch Rate (radians/second) 

Roll Rate (radians/second) 

Yaw Rate (radians/second) 

UTM Northing (meters) 

UTM Easting (meters) 

UTM Zone 

• Dump - Split File: Splits a log file into a smaller file log file based on user provided log start 
and stop time. 
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• Dump - Count PDUs: Provides a tabulation summarizing the following: 


Number of PDUs, 

Number of entity state PDUs, 
Number of data PDUs, 
Number of detonation PDUs, 
Number of fire PDUs, 
Number of start PDUs, and 
Number of stop PDUs. 




Dump - Display Time: Provides a tabulation that displays log time and PDU time 
following formats: 


in the 


Log timestamp (seconds since 1970 and microseconds) 
Log time (milliseconds since midnight) 

Log time (hh:mm:ss.sss) 

PDU timestamp (milliseconds past the hour) 

PDU time (milliseconds since midnight) 

Delta PDU time (time between PDUs) 

Latency (log time - PDU time in milliseconds) 




Dump - Moving Entities: 
are provided: 


Provides a listing for each minute of log time the following data 


Starting log time 
Ending log time 
Starting PDU time 
Ending PDU time 
Number of PDUs 
Number of movements 
Number of entities that moved 


These tools were developed using a foundation of C, C++, Motif, X-Windows 
are transportable to a variety of machines. ' 


and gnuplot and 


The very large data sets and the large numbers of entities associated with the 
significant modifications to the quick-look and real-time analysis software. 

The major modifications were the following: 


ETE tests required 


Entity Selection: For each desired analysis display, the quick-look program provides the 
analyst with the capability to select a set of tests (for a given mission/day), a set of log files 
and, for some analyses, a set of entities. The desired tabulations or plots are displayed 
sequenhally for the selected tests, logs, and entities, and with each display the user is given 
the option to vary the format, print, or display a histogram. This ability to select a set of data 
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for which given analysis displays are desired greatly facilitates processing missions that have 
many tests and many loggers. Previously, the quick-look program read through each selected 
log file to find all of the different entities that were used so they could be displayed to the 
analyst for selection. This worked fine when the files were kilobytes in size and the numbers 
of entities were small, i.e., less than 10. However, for the ETE tests, the files approached 100 
megabytes in size, and the numbers of entities were up to 10,000. Thus, the previous 
program would have to read 100 megabytes, 10,000 times to make sure all of the entities 
were identified. This would have taken hours before the available entities in the selected 
logs could be displayed to the user for selection. Even reading through the very large file 
once took several minutes. Thus, an alternative approach was selected. 

The selected approach was to process the log files once for the entities (and for the start and 
stop PDU and log times - other data needed by the analysis programs that would have 
required reading through the entire file each time) and to save these data in a companion 
.stats file. Thus, establishing the entities within a log file (or the earliest and latest PDU or 
log time) was a simple matter of reading the very short companion .stats file. 

• Entities Selection: Again, due to the large number of entities, a method was needed whereby 
the identification of entities would not be a long, long list of integers. Thus, the handling of 
selected entities was modified so that the user is shown and can identify entities using the 
following example string notation 

1-50, 501-600, 9001-9050 

This string identifies 200 entities that the analyst wants included in the analysis. Similarly, 
the notation is used in the .stats files to tell the analyst (and the software) which entities are 
included in the log file. It greatly reduces the task of identifying entities, albeit with a minor 
increase in software workload. 

• Data Calculations: Previously, the quick-look program read the PDU data needed for 
calculation into data arrays. The array sizes for the System Integration Test were less than 
5,000, i.e., the number of PDUs for any given test were less than 5,000. The data included 
entity number, log time, PDU time, latitude, longitude, and altitude. Thus, the total array 
storage for a given test logger was approximately 

5000 pdus * 6 parameters/pdu * 8 bytes / parameter = 240,000 bytes. 

For ETE, the number of PDUs exceeded 400,000. Thus, the memory that would have been 
required to keep the data in memory would have exceeded 19 megabytes for a given test 
logger. Given all the other memory requirements of the quick-look analysis program, this 
was prohibitive. Thus, it was decided to change all of the data processing routines to 
accomplish their tasks without using data arrays, i.e., read the minimum data required from a 
file to accomplish a calculation (at most this meant two or three PDUs), and then write the 
results to another file for further processing or for display. The result is software insensitive 
to the size of the data files insofar as calculations are concerned. 
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• Entity Number: For previous tests, the entity identification was maintained as a unique 
number among all the sites, i.e., there was only one entity 3. For ETE, as would be expected 
in a large-scale DIS exercise, the entity identification was not unique. The entity 
identification data, i.e., the site ID, host ID, and entity ID combination was unique, so that 
unique entity numbers could be established based on all three fields. This was accomplished 
for both quick-look and real-time analysis programs. 

3.3.3 Data Management and Analysis S ummar y 

The primaiy challenge of an ADS test of a C4ISR system is the potential for a large ADS 
synthetic environment data sets and the use of large numbers of entities. During Phase 1, JADS 
began to gain insight into some of the problems with data management and data analysis; 
however, the development and refinement of data management and data analysis tools will 
continue through future phases of the ETE test. 

An equally important area for investigation in future phases will be the impact on system(s) 
under test data management and data analysis tools. The ADS synthetic environment provides 
the capability to test multiple systems simultaneously, both individually and to determine impacts 
of one system upon another system. The nature of C4ISR will require such tests to be run over 

lonpr periods of time and will produce large data sets requiring improved data management and 
analysis techniques. 
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4.0 Lessons Learned 


4.1 Technical Lessons Learned 

4.1.1 Data Transport Reliability Considerations 

The use of user datagram protocol (UDP) - an inherently unreliable transport mechanism - is not 
always a suitable choice of transport for data that needs a high level of reliability. Routers and 
bridges used to connect subnetworks are the primary source of lost data in networks using UDP. 
The use of UDP forces routers to inspect each packet since it was a broadcast and forward it onto 
each interface. This activity is known as process switching. Since every packet sent is process 
switched, there is a limit to the number of packets successfully received when a node floods the 
network. Testing of several routers confirmed there are definitive “break points” where the 
router processors cannot handle additional packets. 

Routing UDP traffic adds one additional layer of processing (especially when the broadcasts are 
process switched) and creates multiple copies of each datagram in order to forward it to multiple 
network subnets, thus, congesting the network with broadcast traffic. When routing broadcast 
traffic, the network should be designed as flat as possible. Additionally, any routers used should 
be tested to determine their specific break point. 

Bridging UDP traffic precludes the need to process switch each packet and allows the routers to 
use multicasting or unicasting techniques and take advantage of faster switching capability. This 
increases the aggregate number of packets a router can reliably transfer. 

ff reliable transfer of data is required, the transmission control protocol (TCP) is better suited for 
reliable transport since it uses sequencing and acknowledgments, but at a cost of increased 
latency. 

4.2 Programmatic Lessons Learned 

4.2.1 Value of Systems Engineering Process 

The development of an ADS synthetic environment for test and evaluation is a challenging 
activity. The developer must integrate the system(s) under test technology, networking 
technology, simulation technology, and instrumentation technology into an environment. The 
activity requires a multifunctional team of personnel to derive the functional and performance 
requirements, acquire and/or develop the components, and integrate the environment. 

The systems engineering process is used throughout the services and industry as an integral 
process in the development of a system. The process is reiterated during each acquisition phase, 
and whenever a technical change is initiated or needed, to provide progressive definition of the 
system. From the beginning of the JADS Joint Feasibility Study through Phase 1, the IADS ETE 
team has used the process to define and refine the ADS synthetic environment and the 
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components in the environment. Figure 8 is the Defense Systems Management College’s 
depiction of this process. ® 


Process Input 

• Customer Needs^Requirements { 

• Missions 

• Measures of Effectiveness 

• Environments 

• Constra^ts 

• Technology Base 
Output Requirements From 
Prior Phase 
Program Decision 
Requirements 
Requirements Applied Through | 
Specifications arid Standards 


Requirements Analysis 

Analyze Utilization Environments 

• Identify Functional Requirements 

• Define/Refine Performance and Design| 
Constraint Requirements 

. 

Requirements Loop 


System Analysis^ 
and Control 
(Balance) 


Requirements Analysis 

• Decompose to Lower-Level Functions 

• Allocate Performance and Other Limiting Requirements 
to All Functional Levels 

• Define/Refine Functional Interfaces (Intemal/Extemal) 
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Define/Refine/Integrate Functional Architecture 


' Trade-Off Studies 

• Effectiveness Analysis 
' Risk Management 
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Design Loop 


Verification 


Synthesis 

• Transform Architectures (Functional to Physical) 

• Define Alternative System Concepts and System 
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• Define/Refine Physical interfaces (Intemal/Extemal) 
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Related Terms 


Customer = Organizations Responsible for Primary 
Functions 


Primary Functions = Development, Manufacturing, 

Verification, Deployment, Operations 
System Elements = Hardware, Software, Personnel, 

Facilities, Data, Material, Services, 
Techniques 


Process Output 

• Phase Dependent 
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• System/Configuration 
Item Architecture 
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Figure 8. Systems Engineering Process 

Requirements Analysis: The customer’s requirements are derived/defmed/refined and integrated 
m terms of quantifiable characteristics and tasks that the environment must satisfy For each 
requirement, absoluteness, relative priority, and relationship to other requirements are identified 
The impact of the requirements is analyzed in terms of mission, environment, constraints, and 
measures of performance. Impacts are continually examined for validity, consistency 
de^rabihty, and attainability. The output of this analysis is the functional (what) and 
performance (how well) requirements for the environment. 

Funcnonal Analysis/Allocation: Through a functional decomposition all primary environment 
functions and subfunctions are progressively derived/defined/refined to determine the 
actions/tasks an item must perform to satisfy customer needs. Decomposition continues until all 
performance requirements are allocated and all functional relationships are determined. 
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Synthesis: Allocated requirements are satisfied through a bottom up, progressively integrated 
design/synthesis of process and product alternative solutions. Internal and external interfaces are 
analyzed, trade-offs made, and a set of design requirements are established. As design 
requirements are established, verification ensures that all associated functional and physical 
interfaces and functional and performance requirements are satisfied. The resulting set of design 
requirements provides the basis for selecting, developing, and integrating the components of the 
ADS environment. 

System Analysis and Control: Throughout the requirements analysis, functional 

analysis/allocation, and synthesis subprocesses, cost, schedule, performance and risk are 
balanced to provide an environment that is affordable, suitable, and effective. A variety of 
analysis and control tools are available to evaluate design capabilities, to determine progress in 
satisfying technical requirements and technical program objectives, to formulate and evaluate 
alternative designs/courses of actions, and to evolve the environment to satisfy customer needs. 

JADS has learned a key lesson: ADS is not, as some would claim, a “plug and play” technology. 
Developing an ADS environment requires a disciplined process to integrate the various 
technologies and functional disciplines into a usable whole. JADS believes the systems 
engineering process is a proven methodology which can be successfully applied to this challenge. 
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5.0 Future Activities 


Phase 2 of the End-to-End Test consists of planning, preparing, and conducting a developmental 
test activity using some of the components developed in Phase 1 and planning, preparing and 
conducting an operational test activity. 

5.1 Scenario Development 

Each test activity requires the development of one or more scenarios designed to meet the 
objectives of the specific test activity. Scenarios developed for developmental testing are based 
on the system specificarions of the system under test and require careful analysis and testing to 
ensure they meet the objectives of the test. Scenarios developed for operational testing are based 
on a large scale scenario and are focused more on operational realism rather than specification 
^curacy. JADS will develop 2 scenarios for verification and validation, 12 sceneries for 
developmental testing, and TRAC-WSMR will make up to nine scenarios for operational 
testing. Operational test scenarios will be based on an expanded version of a U.S. Army Test and 
Experimentation Command (TEXCOM) scenario. The Road to War, that TEXCOM uses to test 
components of the Army Tactical Command and Control System. The overall scenario is 128 
hours and JADS has selected nine 6-hour vignettes from the scenario to be implemented in 


5.2 Terrain and Feature Database Development 

The SAR simulation developed in Phase 1 requires a highly detailed map of the terrain and 
features on the terrain to develop high quality images. The basic capabilities of the digital terrain 
e evation data (DTED) and digital feature analysis data (DEAD) databases developed by the 
National Imaging and Mapping Agency have neither the quality nor the resolution to meet the 
requirements of the simulation. JADS will apply Geographical Information System (GIS) 
technology to the products to correct errors and enhance the data using information on 150 000 
and 1:100,000 maps. The resulting databases will be used both for the SAR simulation and to 
provide higher quality terrain maps for Janus. 

5.3 Verification, Validation, and Accreditation (W&A) 

VVifeA are key aspects of the Phase 2 effort. A verification and validation plan was developed 
dimng Phase 1 which applied the principles of the DIS Nine-Step VV&A Process and the DoD 
VV&A Process into a VV&A process for JADS ETE. In Phase 2, this plan will be executed, 

resulting m a synthetic environment accredited for use in the JADS ETE operational test at the 
end of Phase 2. 

5.4 Developmental Test 

Ph^e 2 developmental testing will be conducted in conjunction with testing of system upgrades 
by Northrop Grumman. Northrop Grumman is preparing an update to the E-8C software which 
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includes improvements to the automatic tracker function of the operations and control subsystem. 
Previous testing of the tracker has been performed with medium fidelity simulation and multiple 
flight tests. Northrop Grumman has provided specifications for 12 scenarios which are designed 
to test all the tracker requirements. JADS will implement these scenarios in Janus and provide 
log files of the scenarios to Northrop Grumman. Northrop Grumman will use the log files and 
the JADS player tool developed in Phase 1 to test the automatic tracker. JADS will observe 
these tests and collect information from Northrop Grumman relative to the utility of the 
capability. 

5.5 Operational Test 


Phase 2 will culminate with an operational test which uses the entire ETE synthetic environment 
and includes constructive, virtual, and live participants. The operational test is designed to 
evaluated the utility of the environment to support early operational testing or assessments using 
a laboratory environment. Janus will be used to provide constructive targets for the Joint STARS 
sensor being simulated by VSTARS. Radar reports from VSTARS will be sent to E-8C 
workstations in a Northrop Grumman laboratory and will be sent to a ground station module 
(GSM) located at Fort Hood, Texas, using the SCDL interface. The GSM will be in support of a 
subset of the analysis and control element (ACE) who will merge Joint STARS data with other 
intelligence sources to analyze the battlefield and to nominate targets for the Army Tactical 
Missile System (ATACMS). These nominations will be sent to the Depth and Simultaneous 
Attack Battle Lab at Fort Sill, Oklahoma, where doctrinally correct artillery command and 
control will be simulated and eventually a simulated missile will be fired at the target. Messages 
describing the firing and detonation of the missile will be sent back to Janus for assessment of 
damage on the battlefield. Data will be collected which supports the evaluation of operational 
measures of effectiveness to allow JADS to evaluate the utility of the environment to support 
operational testing. 


37 




APPENDIX A 

Architectural Design Report 
for the 

Radar Processor Simulation 
for the 

Joint Surveillance Target Attack Radar System 

(Joint STARS) 


A-l 



ARCHITECTURAL DESIGN REPORT FOR THE 
RADAR PROCESSOR SIMULATION FOR THE JOINT 
SURVEILLANCE TARGET ATTACK 

RADAR SYSTEM (JOINT STARS) 

ESTNO. 14 

RADAR PROCESSOR SIMULATION (RPS) 


DOCUMENT NO. JADS-RPT-001 
DATA ITEM NO. Q002 
March 1996 


CONTRACT NO. F19628-94-C-0040-P00023 
Prepared for: 

Department of the Air Force 
Headquarters Electronics System Center 
Hanscom Air Force Base, Massachusetts 01731 

Prepared by: 

Grumman Aerospace Corporation 
2000 W. Nasa Blvd. 

Melbourne, Florida 32904 


A-3 


TABLE OF CONTENTS 


1 Purpose. 9 

2 Applicable Documents. 12 

3 Trade Study Candidate Definitions.13 

3.1 Candidate Descriptions.13 

3.1.1 Candidate One Description.13 

3.1.1.1 Candidate One Block Diagram.13 

3.1.1.2 Candidate One Interface Requirements.14 

3.1.1.3 Candidate One Hardware Requirements.16 

3. 1 . 1 .4 Candidate One Timeline Requirements.16 

3.1.1.5 Candidate One Software Requirements.18 

3.1.2 Candidate Two Description.21 

3. 1 . 2.1 Candidate Two Block Diagram.21 

3. 1 . 2.2 Candidate Two Interface Requirements.21 

3.1.2.3 Candidate Two Hardware Requirements.22 

3.1.2.4 Candidate Two Timeline Requirements.22 

3.1.2.5 Candidate Two Software Requirements.24 

3.1.3 Candidate Three Description.26 

3.1.3.1 Candidate Three Block Diagram.26 

3.1.3.2 Candidate Three Interface Requirements.27 

3.1.3.3 Candidate Three Hardware Requirements.27 

3.1.3.4 Candidate Three Timeline Requirements.28 

3.1.3.5 Candidate Three Software Requirements.29 

4 Trade Study Process. 31 

4 .1 Candidate Evaluation Criteria.32 

4.1.1 JOINT-STARS Timeline Impact.32 

4.1.2 Memory Requirements.32 

4.1.3 JOINT-STARS System Loading.32 

4.1.4 Modification of Existing Software.32 

4. 1 .5 Modification or Addition of Hardware.32 

4.1.6 Use of Existing Simulations and Models.32 

4.1.7 Level of Simulation. 33 

4.1.8 Integration Requirements. 33 

4.1.9 Expandability/Growth Capabilities. 33 

4.2 Prototype Software Development. 33 

4.3 Hardware. 33 

4.4 Test Scenario.36 

5 Trade Study Results.38 

5.1 Standard Scenario Baseline Results.38 

5.1.1 Timeline Impact Candidate One.38 

5.1.2 Standard Scenario Baseline Memory Requirements. 39 

5.1.3 Standard Scenario Baseline System Loading. 39 

5.2 Trade Study Results Candidate One. 39 

5.2 .1 Timeline Impact Candidate One. 39 

5.2.2 Memory Requirements Candidate One.40 

5.2.3 System Loading Candidate One.40 

5.2.4 Modification of Existing Software Candidate One.41 

5.2.5 Modification or Addition of Hardware Candidate One.42 

5.2.6 Use of Existing Simulations and Models Candidate One.42 

5.2.7 Level of Simulation Candidate One.42 

5.2.8 Integration Complexity Candidate One.42 

5.2.9 Expandability/Growth Candidate One.42 


A-5 






















































6 


5.3 Trade Study Results Candidate Two. 

5.3.1 Timeline Impact Candidate Two. 

5.3.2 Memory Requirements Candidate Two. 

5.3.3 System Loading Candidate Two. 

5.3.4 Modification of Existing Software Candidate Two. 

5.3.5 Modification or Addition of Hardware Candidate Two. 

5.3.6 Use of Existing Simulations and Models Candidate Two., 

5.3.7 Level of Simulation Candidate Two. 

5.3.8 Integration Complexity Candidate Two. 

5.3.9 Expandability/Growth Candidate Two. 

5.4 Trade Study Results Candidate Three. 

5.4.1 Timeline Impact Candidate Three. 

5.4.2 Memory Requirements Candidate Three}. 

5.4.3 System Loading Candidate Three. 

5.4.4 Modification of Existing Software Candidate Three.. 

5.4.5 Modification or Addition of Hardware Candidate Three... 

5.4.6 Use of Existing Simulations and Models Candidate Three 

5.4.7 Level of Simulation Candidate Three. 

5.4.8 Integration Complexity Candidate Three.....11 

5.4.9 Expandability/Growth Candidate Three.11 

Trade Study Conclusions. 


..42 

..42 

..43 

..43 

..44 

,.46 

.46 

.46 

.46 

.46 

.46 

.46 

.47 

.47 

.48 

.50 

.50 

,50 

.50 

,50 

,51 


LIST OF FIGURES 


Figure 1-1 Typical JADS Environment. 

Figure 1-2 JSTARS System Block Diagram. .11111.111 

Figure 1-3 RADAR Subsystem Hardware Block Diagram. 

Figure 1-4 O&C Subsystem Hardware Block Diagram. 

Figure 1-5 RADAR Processing Block Diagram.. .ll.lli.lH 

Figure 3-1 Functional Block Diagram Candidate One. 

Figure 3-2 RADAR Processing Block Diagram.!...l!.l.ll...l" 

Figure 3-3 MTI Simulator Software Interface Requirements. 

Figure 3-4 SAR Timeline. 1 . 

Figure 3-5 MTI Timeline. iZ.llll' 

Figure 3-6 Functional Block Diagram PDU Processing. ...1.111! 

Figure 3-7 SAR Functional Software Flow Diagram Candidate One 

Figure 3-8 Functional Software Flow Diagram Candidate One. 

Figure 3-9 Functional Block Diagram Candidate Two. 

Figure 3-10 SAR Timeline Candidate Two.!!!!!!!!!!!!!! 

Figure 3-11 MTI Timeline Candidate Two.!!!!!!!!!!!!!!!!!!!! 

Figure 3-12 Functional Software Flow Diagram Candidate Two. 

Figure 3-13 Functional Block Diagram Candidate Three.!!!!! 

Figure 3-14 SAR Timeline Candidate Three. 

Figure 3-15 MTI Timeline Candidate Three. 

Figure 3-16 Functional Software Flow Diagram Candidate Three.... 

Figure 4-1 Timing Data Collection Setup Candidate number 1. 

Figure 4-2 Timing Data Collection Setup Candidate number 2.!!! 

Figure 4-3 Timing Data Collection Setup Candidate number 3. 

Figure 4-4 Test Scenario Layout. 

Figure 4-5 Test Scenario Live Target Layout. 

Figure 4-6 Test Scenario Virtual Target Layout. 

Figure 5-1 Standard Scenario Baseline CPU Utilization.! 

Figure 5-2 Standard Scenario Candidate 1 CPU Utilization. 


.9 

...10 

...10 

..11 

..12 

..14 

..15 

..16 

..17 

..17 

..18 

..19 

..20 

,.21 

..23 

..24 

.25 

.26 

.28 

.29 

.31 

.34 

.35 

.36 

.37 

.37 

,38 

.39 

.40 


A-6 




















































Figure 5-3 Standard Scenario Candidate 2 RDP CPU Utilization.43 

Figure 5-4 Standard Scenario Candidate 2 Spare GPC CPU Utilization.44 

Figure 5-5 Standard Scenario Candidate 3 RDP CPU Utilization.47 

Figure 5-6 Standard Scenario Candidate 3 Spare GPC CPU Utilization.48 

LIST OF TABLES 

Table 4-1 Evaluation Criteria...31 

Table 5-1 MTI Baseline Timing.38 

Table 5-2 Estimated Memory Utilization Candidate Number One.40 

Table 5-3 Estimated Modified Lines of Code Candidate Number One....41 

Table 5-4 Estimated Modified Lines of Code Candidate Number Two.45 

Table 5-5Estimated New Lines of Code Candidate Number Three cont'd.:.49 

Table 5-6 Estimated Modified Lines of Code Candidate Number Three.49 

Table 6-1 Evaluation Results Summary.51 


A-7 
















1 Purpose 


This document is intended to report on the results of a study conducted to determine and evaluate 
candidate architectures for the RADAR Processor Simulation (RPS) for the JOINT-STARS 
system, for the purposes of integrating JOINT-STARS into a Joint Advanced Distributed 
Simulation (JADS) environment. A typical JADS environment is shown in Figure 1-1. 



Figure 1-1 Typical JADS Environment 

The general concept of operation for the JSTARS system within such an environment is as 
follows: 

• The JSTARS aircraft will fly over a government controlled facility (such as Ft. Irwin) 

• A small area will contain controlled targets, tanks, trucks, etc. 

• A target/war simulation such as JANUS will be operating at a government facility such as 
White Sands Missile Range (WSMR) generating virtual targets and issuing Protocol Data 
Units (PDUs) on the Distributed Interactive Simulation (DIS) network 

• The RPS will receive the virtual target information, from the DIS network via entity state 
PDUs and supply virtual target RADAR reports combined with the live target RADAR 
reports 

The block diagram for the JSTARS system is shown in Figure 1-2. The JSTARS system consist 
of five subsystems the Operations and Control Subsystem, the Data Link Subsystem, the 
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Communications Subsystem, the RADAR Subsystem, and the Aircraft Subsystem. The focus of 
this study will be on the RADAR Subsystem which is shown in more detail in Figure 1-3. 



Figure 1-2 JSTARS System Block Diagram 



Figure 1-3 RADAR Subsystem Hardware Block D iagr am 
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The RADAR subsystem includes a RADAR Data Processor (RDP) which is a VAX 866 General Purpose 
Computer (GPC), a RADAR Sensor and Programmable Signal Processors (PSPs). The RDP is used to 
control the sensor and process data received from by the sensor. The RADAR sensor is comprised of the 
Line Replaceable Units (LRUs) required to position the Antenna, generate the Radio Frequency (RF) 
signal, amplify and radiate the RF signal, receive the reflected signal and process the signal to a video 
level. The video data in the form of In-Phase and Quadrature (I&Q) data is further processed for target 
detections in the PSPs and RDP. 

Some candidate architectures presented in this report will use a computer designated as the "Spare" 
GPC. This GPC is contained in the O&C Subsystem which is shown in Figure 1-4. The "Spare" GPC 
has access to the same data buses as the RDP, which makes it a prime candidate for performing functions 
similar to the RDP. 


Data Link Dau Bm (DDB) 



FLIGHT MANAGBCNT BUS (FMB) 


Figure 1-4 O&C Subsystem Hardware Block Diagram 


The RADAR processing functional allocation to the hardware components is shown in 
Figure 1-5. 
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Figure 1-5 RADAR Processing Block Diagram 


2 Applicable Documents 


The following is a list of the applicable documents: 


Document Name Date of Issue 

Engineering Services Task (EST) Statement of 21 December 1992 
Work E-8C RADAR Processor Simulation 
System Specification For Joint Surveillance 
Target Attack RADAR System AN/USY-TBD 
(JOINT STARS) 


Revision 


(U) Prime Item Development Specification For 12 June 1991 
RADAR Subsystem AN/APY-(TBD) For Joint 
Surveillance Target Attack RADAR System 
(JOINT STARS) 
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3 Trade Study Candidate Definitions 

3.1 Candidate Descriptions 

The description of each candidate included in the study is provided in the following paragraphs. 
These descriptions are conceptual in nature and are not to be considered design requirement 
definitions. 

3.1.1 Candidate One Description 

This candidate was conceived on the basic premise of minimizing message traffic flow across 
hardware buses and to contain the simulation in the same processing unit as the existing MTI 
processing. 

3.1.1.1 Candidate One Block Diagram 

The functional block diagram for candidate number one is shown in Figure 3-1 the added 
functionality is shown as shaded. This candidate requires that all new functionality be placed in 
the present RADAR Data Processor (RDP) and therefore must meet the present RDP memory 
and CPU loading requirements. 
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Figure 3-1 Functional Block Diagram Candidate One 


3.1.1.2 Candidate One Interface Requirements 

This candidate will interface with the DIS network through the PDU interface module which will 
reside m the RDP. This will be done completely by software and requires no additional hardware 
interface. The RPS will interface with the existing RADAR sensor control (RSC) and signal 
processing (POSTPROC) functions via global common areas in the RDP memory and thus does 
not require any hardware interface bus traffic. 

3.1.1.2.1 DIS Network Interface Processing 

The candidate processor will receive the entity state information from the DIS and perform the 
necessary coordinate transformations. This information will be provided to the SAR simulator 
and the MTI simulator as required, via the Target data base process. 

3.1.1.2.2 RPS Control Interface Requirements 

The candidate one control processing will perform the overall function of controlling the PDU, 
SAR simulator and the MTI simulator and as such will be required to interface on a message 
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level with the existing RDP functions. The RPS control program will contain the capability to 
receive and process the following messages: PSP Parameter messages, and the MTI report 
message. The RADAR processing functional allocation to the hardware components is shown in 
Figure 3-2 with the RPS virtual target injection points shown as shaded. 
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Figure 3-2 RADAR Processing Block Diagram 

3.1.1.2.3 S AR Simulator Interface Requirements 

The SAR simulator must receive navigation, target, terrain and cultural features data from the 
RPS control processor. This data will contain the aircraft platform position as a function of time 
as well as target types, vegetation type, cultural features (such as buildings) and terrain elevation. 
(The terrain data will be obtained from a disk file containing the predefined exercise database.) 

3.1.1.2.4 MTI Simulator Interface Requirements 

The MTI simulator will receive moving target information from the RPS control processor. This 
information will contain target type, target position in TCS coordinates and target velocity. The 
MTI simulator will generate target detection reports which contain target type, target velocity, 
target range, and target cone angle. These interface requirements are shown in Figure 3-3. 


A-15 


























Figure 3-3 MTI Siinulator Software Interface Requirements 

3.1.1.3 Candidate One Hardware Requirements 

resides in the existing RDP and requires no additional hardware or any 
modification to the existing hardware. 

3.1.1.4 Candidate One Timeline Requirements 

This candidate resides in the present RDP which is a Militarized VAX 866 and as such must 
perform in the existing memory and CPU loading environment. The present design utilizes 3.6 

Megab 5 ^es of its existing 64 Megabytes of global common memory and 78.1\% of the CPU is 
loaded. 

3.1.1.4.1 PDU Timeline Requirements 

The relative time line requirements, or sequence of events, for the PDU interface unit is shown in 
Figure3-4 and 3-5. 
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3.1.1.4.2 S AR Simulator Timeline Requirements 

The relative timeline for the present SAR processing is shown in Figure 3-4. The S AR simulator 
must operate within the bounds of this time line. 



INDICATES RPS FUNCTION 

Figure 3-4 SAR Timeline 
3.1.1.4.3 MTI Simulator Timeline Requirements 

The relative timeline diagram for the MTI simulator for candidate number one is shown in Figure 
3-5. The figure shows the relative timeline requirements for each process required to perform the 
simulation. 
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3.1.1.5.3 SAR Simulator Software Requirements 


The S AR simulation will receive terrain, target and other entity state information and perform the 
functions required to generate a proper JOINT STARS SAR image. The SAR simulator will 
format the image information into the proper JOINT STARS format for transmittal over the 
Programmable Signal Processor (PSP) LAN to the RDP. The software functional flow for the 
SAR processing for candidate one is shown in Figure 3-7. 



Figure 3-7 SAR Functional Software Flow Diagram Candidate One 
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3.1.1.5.4 MTI Simulator Software Requirements 


The MTI simulator will receive target entity state messages from the RPS control process and 
perform the necessary functions to emulate the JOINT STARS MTI signal processing. The 
simulation will be performed on a dwell basis. The software functional flow for the MTI 
processing for candidate one is shown in Figure 3-8. 
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Figure 3-8 Functional Software Flow Diagram Candidate One 
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3.1.2 Candidate Two Description 


This candidate was conceived with the idea of minimizing the impact to the present processing 
by isolating the new functionality in an independent processor. These would require that the 
functionality of the spare General Purpose Computer (GPC) be replaced for the exercise period. 

3.1.2.1 Candidate Two Block Diagram 

The functional block diagram for candidate number two is shown in Figure 3-9 the added 
functionality is shown as shaded. This candidate requires that the majority of new functionality 
be placed in the present spare General Purpose Computer. Some control functions will reside in 
the present RDP as shown in the figure. 


DIS LAN 



Figure 3-9 Functional Block Diagram Candidate Two 

3.1.2.2 Candidate Two Interface Requirements 

This candidate will interface with the DIS network through the target data base module which 
will reside in the Spare GPC. This will be done via a LAN interface. The RPS will interface 
with the existing RADAR sensor control (RSC) and signal processing (POSTPROC) functions 
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via the PSP and OWS LAN interfaces using message structures which have been developed for 
communication with the PSPs and CDPs. 

3.1.2.2.1 DIS Network Interface Processing 

The candidate processor will receive the entity state information from the DIS and perform the 
necessary coordinate transformations. This information will be provided to the SAR simulator 
and the MTI simulator as required, via the Target data base process. 

3.1.2.2.2 RPS Control Interface Requirements 

The c^didate two control processing will perform the overall function of controlling the PDU, 
SAR simulator and the MTI simulator and as such will be required to interface on a message 
level with the existing RDP functions on the OWS LAN interface. The RPS control program 
will contain the capability to receive and process the following messages: PSP Parameter 
messages, and the MTI report message. 

3.1.2.2.3 SAR Simulator Interface Requirements 

The SAR simulator must receive navigation and target data from the RPS control processor. 
This data will contain the aircraft platform position as a function of time as well as target types 
and orientation. The SAR simulator will maintain a data base of hypsographic and cartographic 
data required to develop the SAR image. 

3.1.2.2.4 MTI Simulator Interface Requirements 

The MTI simulator will receive moving target information from the RPS control processor. This 
information will contain target type, target position in TCS coordinates and target velocity. The 
MTI simulator will generate target detection reports which contain target type, target velocity, 
target range, and target cone angle. 

3.1.2.3 Candidate Two Hardware Requirements 

This candidate resides in the existing spare GPC and requires no additional hardware but will 
cause the spare GPC to be reconfigured to the RPS. 

3.1.2.4 Candidate Two Timeline Requirements 
3.1.2.4.1 PDU Timeline Requirements 

The relative time line requirements, or sequence of events, for the PDU interface unit is shown in 
Figure 3-10 and Figure 3-11. 
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3.1.2.4.2 SAR Simulator Timeline Requirements 


The relative timeline for the present SAR processing is shown in Figure 3-10. The SAR 
simulator must operate within the bounds of this time line. 
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Figure 3-10 SAR Timeline Candidate Two 
3.1.2.4.3 MTI Simulator Timeline Requirements 

The relative timeline diagram for the MTI simulator for candidate number two is shown in Figure 
3-11. The figure shows the relative timeline requirements for each process required to perform 
the simulation. 
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Figure 3-11 MTI Timeline Candidate Two 

3.1.2.5 Candidate Two Software Requirements 

The following software functions must be developed for this candidate; DIS network interface, 
RPS control. Dead reckoning processing, SAR simulator, MTI simulator and report processing. 

3.1.2.5.1 RPS Control Software Requirements 

The RPS control software will be required to perform the simulation initialization, event time 
line control, simulator control, simulation shut down and error handling. 

3.1.2.5.2 PDU Software Requirements 

The PDU software will perform all interface functions required to send, receive and decode 
entity state messages received on the DIS network. The PDU software will also be required to 
perform all necessary coordinate conversions and target information updating (dead reckoning). 
The PDU software will be divided into two distinct components, the DIS network interface and 
the Target data base process. The DIS network interface will be hosted on a Unix based 
workstation, which will have the necessary software to interface over a LAN to an RF data link. 
The Target data base process will be hosted in the same processor as the MTI simulator and will 
also interface with an RF Data link. The processing flow diagram for the PDU process is shown 
in Figure 3-6. 
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3.1.2.5.3 SAR Simulator Software Requirements 


The SAR simulation will receive terrain, target and other entity state information and perform the 
functions required to generate a proper JOINT STARS SAR image. The SAR simulator will 
format the image information into the proper JOINT STARS format for transmittal over the 
Programmable Signal Processor (PSP) LAN to the RDP. The software functional flow for the 
SAR processing for candidate two is shown in Figure 3-7. 

3.1.2.5.4 MTI Simulator Software Requirements 


The MTI simulator will receive virtual target data from the RPS control process and perform the 
necessary functions to emulate the JOINT STARS MTI signal processing. The simulation will 
be performed on a dwell basis. The software functional flow for the MTI processing for 
candidate two is shown in Figure 3-12. 



Figure 3-12 Functional Software Flow Diagram Candidate Two 
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3.1.3 Candidate Three Description 


This candidate was conceived with the idea of increasing the fidelity of the simulation or 
lowering the level at which the simulation will be performed. This candidate will develop 
RADAR models and simulations at the Coherent Processing Interval (CPI) level. 
Implementation of this candidate will require modeling the PSP detection process. The 
functionality of the spare General Purpose Computer (GPC) be replaced by the RPS. 

3.1.3.1 Candidate Three Block Diagram 

The fonctional block diagram for candidate number three is shown in Figure 3-13 the added 
functionality is shown as shaded. This candidate requires that all of the new functionality be 
placed in the present spare GPC. The processing required in candidate number three will be 
performed at the coherent processing interval (CPI) level. This will require that the RPS capture 

the PSP Nodel message and inject the virtual targets every CPI. This will have some impact on 
the RADAR timeline. 


DIS LAN 



Figure 3-13 Functional Block Diagram Candidate Three 
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3.1.3.2 Candidate Three Interface Requirements 

This candidate will interface with the DIS network through the PDU interface module which will 
reside in the Spare GPC. This will be done completely by software and requires no additional 
hardware interface. The RPS will interface with the existing RADAR sensor control (RSC) and 
signal processing (POSTPROC) functions via the PSP and OWS LAN interfaces using message 
structures which have been developed for communication with the PSPs and CDPs. 

3.1.3.2.1 DIS Network Interface Processing 

The candidate processor will receive the entity state information from the DIS and perform the 
necessary coordinate transformations. This information will be provided to the SAR simulator 
and the MTI simulator as required, via the Target data base process. 

3.1.3.2.2 RPS Control Interface Requirements 

The candidate three control processing will perform the overall function of controlling the PDU, 
SAR simulator and the MTI simulator and as such will be required to interface on the PSP LAN 
with the existing RDP functions. Portion of the control process will reside in the spare GPC and 
the RDP. The RPS control program will contain the capability to receive and process the 
following messages: PSP Setup messages, PSP Parameter messages, the MTI report node 1 
message, and the PSP node 2 messages. 

3.1.3.2.3 SAR Simulator Interface Requirements 

The SAR simulator must receive navigation and target data from the RPS control processor. 
This data will contain the aircraft platform position as a function of time as well as target types 
and orientation. The SAR simulator will maintain a data base of hypsographic and cartographic 
data required to develop the SAR image. 

3.1.3.2.4 MTT Simulator Interface Requirements 

The MTI simulator will receive moving target information from the RPS control processor. This 
information will contain target type, target position in TCS coordinates and target velocity. The 
MTI simulator will generate target locations in range; cone angle and associate these target 
characteristics with the appropriate CPIs. These targets will be added to the existing node 1 
message which is transmitted by the PSP to the RDP via the PSP LAN. 

3.1.3.3 Candidate Three Hardware Requirements 

This candidate resides in the existing spare GPC and requires no additional hardware but will 
cause the spare GPC to be reconfigured to the RPS. 
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3.1.3.4 Candidate Three Timeline Requirements 


3.1.3.4.1 PDU Timeline Requirements 

The relative time line requirements, or sequence of events, for the PDU interface unit is shown in 
Figure 3-14 and Figure 3-15. 


3.1.3.4.2 SAR Simulator Timeline Requirements 

The relative timeline for the present SAR processing is shown in Figure 3-14. The SAR 
simulator must operate within the bounds of this time line. 
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Figure 3-14 SAR Timeline Candidate Three 
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3.1.3.4.3 MTI Simulator Timeline Requirements 

The relative timeline diagram for the MTI simulator for candidate number three is shown in 
Figure 3-15. The figure shows the relative timeline requirements for each process required to perform 
the simulation. 
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Figure 3-15 MTI Timeline Candidate Three 


3.13.5 Candidate Three Software Requirements 

The following software functions must be developed for this candidate ; DIS network interface, 
RPS control. Dead reckoning processing, SAR simulator, MTI simulator and node 1 and node 2 
report processing. 

3.1.3.5.1 RPS Control Software Requirements 

The RPS control software will be required to perform the simulation initialization, event time 
line control, simulator control, simulation shut down and error handling. 
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3.1.3.5.2 PDU Software Requirements 


The PDU software will perform all interface functions required to send, receive and decode 
entity state messages received on the DIS network. The PDU software will also be required to 
perform all necessary coordinate conversions and target information updating (dead reckoning). 
The PDU software will be divided into two distinct components, the DIS network interface and 
the Target data base process. The DIS network interface will be hosted on a Unix based 
workstation, which will have the necessary software to interface over a LAN to an RF data link. 
Target data base The process will be hosted in the same processor as the MTI simulator and will 
also interface with an RF Data link. The processing flow diagram for the PDU process is shown 
m Figure 3-6. 

3.1.3.5.3 SAR Simulator Software Requirements 

The SAR simulation will receive terrain, target and other entity state information and perform the 
functions required to generate a proper JOINT STARS SAR image. The SAR simulator will 
format the image information into the proper JOINT STARS format for transmittal over the 
Programmable Signal Processor (PSP) LAN to the RDP. The software functional flow for the 
SAR processing for candidate three is shown in Figure 3-7. 

3.1.3.5.4 MTI Simulator Software Requirements 

The MTI simulator will receive target entity state messages from the RPS control process and 
perform the necessary functions to emulate the JOINT STARS MTI signal processing. The 
simulation will be performed on a CPI basis. The software functional flow for the MTI 
processing for candidate three is shown in Figure 3-16. 
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Figure 3-16 Functional Software Flow Diagram Candidate Three 
4 Trade Study Process 


The following paragraphs comprise the trade study evaluation requirements for the architectural 
study for the RPS. Architecture candidates were identified and evaluated based on the criteria 
described in the following paragraphs. The criteria and their associated weights are given in 
Table 4-1 Evaluation Criteria. Each criterion was assigned a pre-weighted value from 1 to 3 
based on the candidates impact on the specific criteria. 



Criterion 


Timeline Impact 
Memory Requirements 
System Loading 

Modification of Existing Software 
Modification or Addition of Hardware 
Use of Existing Simulations and Models 
Level of Simulation 
Integration Complexity 
Expandability/Growth 



Table 4-1 Evaluation Criteria 
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4.1 Candidate Evaluation Criteria 


The conceptual architectural designs were evaluated on the criteria delineated in the following 
paragraphs. Each criterion was assigned a weighting factor to be used in the evaluation process. 

4.1.1 JOINT-STARS Timeline Impact 

Each candidate was evaluated based on its impact to the present JOINT-STARS timeline. Those 
candidates which have the smallest impact on the timeline were given the higher scores. 
Timeline impacts to the RADAR subsystem are more heavily weighted than impacts to the 0\&C 
subsystem. The RADAR timeline has more effect on total system performance. 

4.1.2 Memory Requirements 


Each candidate was evaluated based on the amount of memory required to implement the design. 
Those candidates with lower memory requirements received higher ratings. 

4.1.3 JOINT-STARS System Loading 

Each candidate was evaluated based on its effect on maximum system loading capabilities. 
Those candidates with least effect were given higher ratings. 

4.1.4 Modification of Existing Software 

Each candidate was evaluated based on the amount of changes to existing software. The goal 
was to minimize changes to the present JSTARS software in order to reduce regression testing 
liability. However, minor changes are acceptable and expected. Candidates requiring the least 
amount of changes to existing software achieved the highest ratings. 

4.1.5 Modification or Addition of Hardware 

Each candidate was evaluated based on the amount of modifications required to existing 
hardware or the addition of hardware. It was desired not to make any hardware changes 
therefore, candidates requiring hardware changes/additions received low ratings. 

4.1.6 Use of Existing Simulations and Models 

Each candidate was evaluated based on the number of simulations and models to be developed 
versus use of existing code. The candidates which require the least new code development 
received the highest ratings. 
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4.1.7 Level of Simulation 


Each candidate was evaluated based on the level of the simulations used. It was desired to keep 
the simulations and models at the highest level possible (e.g. simulated at the target report level). 
Those candidates which require lower level simulations and models are given lower ratings 
because in general they will have increased complexity. 

4.1.8 Integration Requirements 

Each candidate was evaluated based on its integration requirements, that is to say, the amount of 
hardware, software and facilities required for integration purposes. The candidates which require 
the most hardware, software and facilities obtained lower ratings. 

4.1.9 Expandability/Growth Capabilities .. 

Each candidate was evaluated based on its capability of being expanded at a later date. These 
candidates will incorporate more general design concepts that inherently lead to their 
expandability. These candidates will receive higher ratings than those which restrict or inhibit 
future growth. 

4.2 Prototype Software Development 

The trade study was performed on the candidates delineated in the previous paragraphs of this 
report. In most cases the information used to conduct the trade study was available from the 
conceptual design process of the candidate. However, in some limited cases the information was 
not obtainable from the conceptual design, in these cases some level of prototype software code 
development was necessary. Prototype code is defined as code which performs the desired 
functionality but which has not been optimized for performance. As an example prototype code 
will in some cases utilize stubs. Stubs are subroutine calls which return immediately to the 
calling process without performing any calculations or function. This allows the testing of 
message flow and handling without performing the detail design function. 

4.3 Hardware 

In most cases the Prime Mission Equipment (PME) was not available for performing in depth 
timing studies. Therefore, an alternate hardware host was used for timing comparisons. A VAX 
4000 series 90 was used as the host. Increased performance may be expected when the code is 
hosted on the targeted PME processors. The timing data presented in this report must be viewed 
as a relative measure of performance and should not be used to predict absolute performance. 
The hardware set up for the timing data collection is shown in Figure 4-2 and Figure 4-3. 
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Figure 4-1 Timing Data Collection Setup Candidate number 1 
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Figure 4-2 Timing Data Collection Setup Candidate number 2 
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Figure 4-3 Timing Data Collection Setup Candidate number 3 

4.4 Test Scenario 


In order to compare timeline impacts, memory utilization and other trade study criteria it was 
necessary to develop a standard test scenario. This scenario consists of a virtual target area (24 
X 24 km) and a live target area (4 km x 4 km). The virtual area will typically be larger than 
the live target area. The area of interest (AOI) is the search area (10 km x 10 km) as requested by 
the operator and is where the combination of live and virtual targets will be reported. A diagram 
of the scenano is shown in Figure 4-4. The live area contains 60 targets (as shown in Figure 4-5) 
and the virtual area contains 5000 targets as shown in Figure 4-6). All trade study tests use this 
scenario for determining performance. 
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Figure 4-5 Test Scenario Live Target Layout 
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5 IVade Study Results 


This ^tion will present the results of the trade study for each candidate. The criteria is shown 
m Table 4-1 Evaluation Cnteria. The perfoimance of each candidate was evaluated for each of 
the cntenon listed and the results are presented in this section of the report. 

5.1 Standard Scenario Baseline Results 

5.1.1 Timeline Impact Candidate One 

The timing results presented here will be of a relative nature only since the actual RADAR 

timeline is a very complex non-linear function of target loading. The baseline RDP timeline is 
shown in Table 5-1. 


Measurement 

POINT 

Average 
Number of 
Dwells 

Average Time 
(msec) Per 
Dwell 

$T_2-T_1$ 

158 

1,739 

$T_4 - T_3$ 

rT58 

^ 30 


Table 5-1MTI Baseline Timing 
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5.1.2 Standard Scenario Baseline Memory Requirements 

The memory requirements presented here will be of a relative nature only since the actual 
RADAR memory utilization is target dependent. The baseline RDP memory utilization is 3.6 
megabytes. 

5.1.3 Standard Scenario Baseline System Loading 

The CPU utilization for the standard target scenario is shown in Figure 5-1. The CPU utilization 
for the MTI processes,PK4MTI and PK4RPT are very low since the target load is low. The 
process PKXAUX which reads the sensor auxiliary data from a recorded file actually takes more 
CPU time than the MTI processing. 


VAXA'MS Monitor utility 


PKSRPT 
PKXOCO 
CPU MONITOR 
PK4MTI 
DECW$TE_0129 
PKXAUX 



-t- 

40 60 

CPU Percent Utilization 


Figure 5-1 Standard Scenario Baseline CPU Utilization 


5.2 Trade Study Results Candidate One 

The following paragraphs describe the performance expected for candidate number one. 

5.2.1 Timeline Impact Candidate One 

The timing data was collected with a set dead reckoning update rate of 10 hz. This was done to 
investigate the effect of worst case dead reckoning on the overall timeline. The estimated timing 
for candidate number one is summarized in Table ~\ref{time_one_10hz}. 
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\input{ sw_time_c l_10hz.tex} 

5.2.2 Memory Requirements Candidate One 

The estimated additional memory utilized for candidate number one over the baseline 3.6 
megabytes is summarized in Table 5-2. 


Process 

Name 

5,000 

DIS TGTS 

10,000 

DIS TGTS 

20,000 

DIS TGTS 

MTIRPT 

MTISIM 

DISNIU 

DISNIU (DR) 

PK4MTI 

PK4RPT 

1.2 Mbyte 
3.6 Mbyte 
2.4 Mbyte 
n/a 
n/a 
n/a 

2.4 Mbyte 
7.2 Mbyte 
4.8 Mbyte 
n/a 
n/a 
n/a 

4.8 Mbyte 
14.4 Mbyte 
9.6 Mbyte 
n/a 
n/a 
n/a 


Table 5-2 Estimated Memory Utilization Candidate Number One 
5.2.3 System Loading Candidate One 

A typical CPU utilization plot for candidate number one is shown in Figure 5-2. The JADS DIS 
process takes most of the available CPU with an average CPU utilization of 60\% for this case. 


VAX/VMS Monitor Utility 



Figure 5-2 Standard Scenario Candidate 1 CPU Utilization 
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5.2.4 Modification of Existing Software Candidate One 

The new software modules which will be required to be developed for candidate number one are 
shown in Tables -\ref{sw_new_rpt_one}, \ref{sw_new_sim_one} and \ref{sw_new_dis_one}. 

\input{ new_code_c l_rpt_table.tex} 

\input{new_code_c l_sim_table.tex} 

\input{ new_code_c l_dis_table.tex} 

The estimated modified lines of code for candidate number one is summarized in Table 5-3. 


PK4RPT Process 

Software Module 

Function 

Lines of 

Code 

SKRPO l_MTI_REPORT 

Main program unit for 
this process. 

3 

SKRP02_INIT_REPORT 

Initializes the PK4RPT 
process to JSTARS s/w. 

Added mapping to the 
GLIV_M'n_DATA global 
section. 

2 

SKRP05_RETRIEVE_DATA 

Receives incoming 
messages. Modified to 
receive the RPT_TEST_ 
PARAMS_CQ message from 
the MTIRPT process. 

8 

SKRPOB_DATA_TO_OCO 

Sends the final MTI 
report onto the MTI 

DATA MOT queue. 

Modified to put the 

Live MTI data into the 
GLrV_MTI_DATA global 
section instead of the 

Mn DATA MOT queue, 
and subsequently 
notify MTIRPT that the 

Live MTI data is ready 

17 

PK4RPT Totals: 


29 


Table 5-3 Estimated Modified Lines of Code Candidate Number One 
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5.2.5 Modification or Addition of Hardware Candidate One 

Candidate number one does not require the modification or addition of any hardware comoonents 
to the JSTARS system. 

5.2.6 Use of Existing Simulations and Models Candidate One 

Candidate number one uses the screening code and coordinate conversion code which was 
developed during the Joint STARS FSD program. 

5.2.7 Level of Simulation Candidate One 


■^e RPS candidate number one is implemented at the RADAR report level. This means that all 

the MTI target detection, target classification, and location accuracy processing are simulated by 
the RPS. 

5.2.8 Integration Complexity Candidate One 

The integration complexity of candidate one is high because the RPS is not well partitioned from 
the JOOT STARS prime mission equipment (PME) software. The ideal integration situation is 
to be able to monitor data flow between processes on an external interface. This will not be 
possible with candidate number one since it resides in the same processor as the PME software. 
Therefore intrusive software techniques must be used, such as debuggers, to determine faults. 

5.2.9 Expandability/Growth Candidate One 


The expandability of RPS candidate number one is limited by the fact that candidate number one 
IS running in the same processors as the PME software and will start to effect the timeline under 
the full target loading. The exact point at which the live targets are effected were not determined 
dunng this study. However, some indication of the effect can be seen in the time data versus 
virtual target load presented in Table ~\ref{time_one_10hz}. 

5.3 Trade Study Results Candidate Two 


The following paragraphs describe the performance expected for candidate number two. 

5.3.1 Timeline Impact Candidate Two 

The dming results presented here will be of a relative nature only since the actual RADAR 
timeline is a very complex non-linear function of target loading. The estimated timing for 
candidate number two is summarized in Table ~\ref{time_two_10hz}. 

\input {sw_time_c2_ 1 Ohz.tex} 
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5.3.2 Memory Requirements Candidate Two 

The memory requirements presented here will be of a relative nature only since the actual 
RADAR memory utilization is target dependent. The baseline SPARE GPC memory utilization 
is zero during normal RADAR operation. The estimated SPARE GPC memory utilization for 
candidate number two is summarized in Table ~\ref(memory_two}. 

\input {sw_memory_c2.tex} 

5.3.3 System Loading Candidate Two 

A typical CPU utilization plot for candidate number two is shown in Figure 5-3 for the RDP 
processes and Figure 5-4 for the Spare GPC processes. The JADS DIS process takes most of the 
available CPU with an average GPC CPU utilization of 75\% for this case. 


VAX/VMS Monitor Utility 

OPCOM 

DMQ_S_CXD800004 
PK4RPT_JADS2 

PKXOCO 

DMQQ_C_0008000 
04 

PK4MTI_JADS2 
DEC\A/$TE_0129 
PKAUX_JADS2 


Figure 5-3 Standard Scenario Candidate 2 RDP CPU Utilization 



0 20 40 60 80 100 

CPU Percent Utilization 
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VAX/VMS Monitor Utility 



Figure 5-4 Standard Scenario Candidate 2 Spare GPC CPU Utilization 


5.3.4 Modification of Existing Software Candidate Two 


software modules which will be required to be developed for candidate number two are 
shown in Tables ~\ref{sw_new_rpt_one}, Vef{sw_new_sim_two} and \ref{sw_new_dis_two}. 


\input{ new_code_c2_rpt_table.tex} 
\input{ new_code_c2_sim_table.tex} 
\input{ new_code_c2_dis_table.tex} 


The estimated modified lines of code for candidate number two is summarized in Table 5-4. 
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PK4RPT Process 

Software Module Function Lines of Code 

SKRP01\_MTI\_REPORT 

SKRP02\_INIT\_REPORT 

Main program unit for 
this process. 

Initializes the PK4RPT 
process to JSTARS s/w. 
with JADS 

3 

32 

SKRP05\_RETRIEVE\_DATA 

Receives incoming 

messages. Modified to 

receive the 

RPT\_TEST\_ 

PARAMS\_CQ 

message from 

the MTIRPT process. 

14 

SKRP08\_DATA\_TO\_OCO 

Sends the final MTI 
report onto the MTI 
DATA MOT queue. 
Modified to send the 

Live MTI data to the 
spare GPC. 

33 

SKRP99\_SHUTDOWN 

Dumps Timing data to 
file whenever PK4RPT 
shuts down 

52 

PK4RPT Totals: 134 

PK2MCP Process 

SK2M1 l\_PROCESS\_MOCOMP\_DATA 

Receives incoming 
messages. Modified to 
receive the 

MCP\_TEST\_ 

PARAMS message 

from 

the MTIRPT process. 

2 

SK2M\_BLD\_MTI\_PSP\_PARAM\_MSG 

Builds and sends the 

MTI\_PARAMETERS 

message 

to the PSPs. Modified 
to send this message 
to the MTISIM process 
for the first CPI in a 
dwell as well as send 
to the PSPs. 

6 

1 PK2MCP Totals: 8 I 

1 Total Modifled lines 

142 1 


Table 5-4 Estimated Modified Lines of Code Candidate Number Two 
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5.3.5 Modification or Addition of Hardware Candidate Two 


Candidate number two does not require the modification or addition of any hardware components 
to the JSTARS system. 

5.3.6 Use of Existing Simulations and Models Candidate Two 


Candidate number two uses the screening code and coordinate conversion code which 
developed during the Joint STARS FSD program. 


was 


5.3.7 Level of Simulation Candidate Two 


The m candidate number two is implemented at the RADAR report level. This means that all 
the detection, target classification, and location accuracy processing are simulated by 


5.3.8 Integration Complexity Candidate Two 

of candidate two is low because the RPS is well partitioned from the 
JOINT STy^S pnme mission equipment (PME) software. During integration data flow can be 

P^^^ible using standard 

JOINT STARS recording equipment. 

5.3.9 Expandability/Growth Candidate Two 

The expandability of RPS candidate number two is limited only by the existing memory 
capability and processing speed of the Spare GPC. This is tnie due to the fact that candidate 

numto two only effects the MTI report delivery time to the 0\&C subsystem which will not be 
detectable by the operator. 

5.4 Trade Study Results Candidate Three 


The following paragraphs describe the performance expected for candidate number three. 
5.4.1 Timeline Impact Candidate Three 


The timing results presented here will be of a relative nature only since the actual RADAR 
timeline is a very complex non-linear function of target loading. The estimated timing for 
candidate number three is summarized in Table ~\ref{time_three_10hz}. 

\input {sw_time_c3_ 1 Ohz.tex} 
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5.4.2 Memory Requirements Candidate Three} 

The memory requirements presented here will be of a relative nature only since the actual 
RADAR memory utilization is target dependent. The baseline SPARE GPC memory utilization 
is zero during normal RADAR operation. The estimated SPARE GPC memory utilization for 
candidate number three is summarized in Table ~\ref{memory_three}. 

\input {s w_memory_c3 .tex} 

5.4.3 System Loading Candidate Three 

A typical CPU utilization plot for candidate number three is shown in Figure 5-5 for the RDP 
processes and Figure 5-6 for the Spare GPC processes. The JADS DIS process takes most of the 
available CPU with an average GPC CPU utilization of 75\% for this case. 


VAX/VMS Monitor Utility 

OPCOM 

DMQ_S_00800004 

PK4RPT_JADS2 

PKXOCO 
DMQQ_C_0008000 ‘ 

04 

PK4MTLJADS2 
DECW$TE_0129 
PKAUX_JADS2 

0 20 40 60 80 100 

CPU Percent Utilization 

Figure 5-5 Standard Scenario Candidate 3 RDP CPU Utilization 


H-1- 
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VAX/VMS Monitor Utility 



Figure 5-6 Standard Scenario Candidate 3 Spare GPC CPU Utilization 
5.4.4 Modification of Existing Software Candidate Three 


The new software modules which will be required to be developed for candidate number three 
are shown in Tables ~Vef{sw_new_JDSNDl .three}, \ref{sw_new_sim_three} and 
Vef{sw_new_dis_three}. The estimated modified lines of code for candidate number three is 
summarized in Table ~\ref{sw_mod_three_ncp}. 

\input {new_code_c3_JDSND 1 _table.tex} 

\input{ new_code_c3_sim_table.tex 
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1 JADS DISNIU PROCESS | 

Software Module 

Function 

Lines of Code 

DISNIU_Fill 

Simulates Reception of 

DIS PDUs 

60 

DISNIU_FILTER_PDUs 

Filters Entity State 

PDUs 

36 

DISNIU_Main 

Init socket interface 
receive msg from DIS LAN 
maps to MTISIM common DB 
performs dead reckoning 

180 

DISNIU_REPORT 

Dumps PDU DataBase Time 
numbers to file 

21 

DISNIU_DR_Report 

Dumps dead reckoning 
timing numbers to file 

20 

Init_Topo 

init topo origin 

10 

Geoc_To_Topoc 

convert from Geo to 

Topo coordinates 

10 

T opoc_T o_Geoc 

convert from Topo to 

Geo coordinates 

10 

Geod_To_Geoc 

convert from Geod to 

Geo coordinates 

8 

Byte_Swap_Lword 

byte swap 4 byte word 

10 

Byte_Swap_Word 

byte swap 2 byte word 

8 

Lword_Swap_To_Dword 

byte swap 8 byte word 

7 

VAX2IEEE_Init 

VAX to IEEE initialize 

3 

VAX2ffiEE_Short 

VAX to IEEE single prec 

3 

VAX2ffiEE_Float 

VAX to IEEE Float point 

4 

VAX2IEEE_Double 

VAX to IEEE double prec 

5 

CVT_DIEEE_TO_DVF 

converts little endian/ 

IEEE value to VAX value 

12 

CVT_DVF_TO_DIEEE 

converts VAX value to 
little endian/IEEE value 

11 

CVT_IEEE_TO_VF 

converts little endian/ 

IEEE value to VAX value 

10 

CVT_VF_TO_IEEE 

converts VAX value to 
little endian/IEEE value 

10 

DISNIU Totals: 


438 


Table 5-5Estimated New Lines of Code Candidate Number Three cont'd 


PTNOWA Process 

Software Module 

Function 

Lines of Code 

Main 

Main program unit for 
this process. 

222 

PTNOWA Totals: 


222 


Table 5-6 Estimated Modified Lines of Code Candidate Number Three 
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5.4.5 Modification or Addition of Hardware Candidate Three 

Candidate number three does not require the modification or addition of any hardware 
components to the JSTARS system. 

5.4.6 Use of Existing Simulations and Models Candidate Three 

The level at which candidate number three injects the virtual targets requires that all new models 
and simulations be developed. 

5.4.7 Level of Simulation Candidate Three 


The RPS candidate number three is implemented at the RADAR CPI level. This means that all 
the target classification, and location accuracy processing are simulated by the RPS. 

5.4.8 Integration Complexity Candidate Three 

^e integration complexity of candidate three is lower than candidate number one because the 
IS well partitioned from the JOINT STARS prime mission equipment (PME) software 
Dunng integration we will be able to monitor data flow between processes on an external 
interface. This will be possible using our standard JOINT STARS recording equipment. 

However, the complexity is greater than candidate number two because of the content and 
volume of the message data 

transferred between processors. 

5.4.9 Expandability/Growth Candidate Three 

The expandability of RPS candidate number three is limited by the existing memoiy capability 
and processing speed of the Spare GPC. The candidate number three software must handle every 
Node 1 message and therefore by it’s very nature impact the RADAR timeline. This timeline 
effect will be noticeable under full target load. 
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6 TVade Study Conclusions 


The following paragraphs comprise the results of the architectural trade study for the JADS RPS. 
An overall summary of the trade study results are given in Table 6-1. 



Cnterion 

Weight 

Number 1 

Number 2 

Number 3 

Timeline Impact 

10 

2 

3 

1 

Memory Requirements 

2 

1 

3 

1 

System Loading 

8 

1 

3 

9 

Modification of Existing Software 

9 

1 

2 

3 

Modification or Addition of Hardware 

6 

3 

3 


Use of Existing Simulations and Models 

4 

3 

3 

D 

3 

Level of Simulation 

4 

2 

2 


Integration Complexity 

5 

1 

2 

9 

Expandibility/Growth 

6 

1 

3 

3 

Total 


88 

144 

127 


Table 6-1 Evaluation Results Summary 

Candidate number two is the clear choice for the JADS implementation in the JOINT STARS 

system It is low risk with acceptable performance. The following general conclusions can be 

drawn from the architectural study. 

• Candidate number one has the most undesirable effect of being able to limit the radar's 
performance due to timeline, memory and CPU utilization. 

• Candidate number two has the least impact on radar performance. The delay that is incurred 
m this candidate is only a delay in delivery of the reports to the operator and as such does not 
impact radar timeline or performance. 

• Candidate number three has more of an advantage from a testing stand point in that it can be 
used to throughly test the Radar Data Processor processes. It can however, under full target 
load have a severe effect on the radar timeline. 
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1. Scope 


This document establishes the hardware and software requirements to meet the system design 
goals for the Radar Processor Simulation (RPS) being developed for the purposes of integrating 
Joint-STARS into a Joint Advanced Distributed Simulation (JADS) environment. The 
requirements specified in this document are for those techniques specific to the development of 
the RPS in the JADS environment. Algorithms and techniques developed for Joint STARS are 
referenced in this document, but are not specified in detail. A typical JADS environment is 
shown I Figure l.-l. 



Figure l.-l. Typical JADS Environment 


The general concept of operation for Joint STARS within such an environment is as follows: 

• The Joint STARS aircraft will fly over a government controlled facility (such as Ft. 
Irwin) 

• A small area will contain controlled targets, tanks, trucks, etc. 
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• A target / war simulation such as JANUS will be operating at a government facility 
such as White Sands Missile Range (WSMR) generating virtual targets and issuing 
Protocol Data Units (PDUs) on the Distributed Interactive Simulation (DIS) network 

• The RPS will receive the virtual target information, from the DIS network via entity 

state PDUs and supply virtual target radar reports combined with the live target radar 
reports 

Figure 1.-2 is a block diagram for Joint STARS identifying the functional layout of its five 
subsystems; (1) Operations and Control; (2) Data Link; (3) Communications; (4) Radar- and (5) 
Aircraft Subsystems. 



The Architectural Design Report (JADS-RPT-001) referenced in section 2 proprosed three 
candidate architectures to implement the RPS within Joint STARS. One of the primary design 
goals presented in the Architecture Design Report is minimizing modification to existing Joint 
STARS software. With this goal in mind, all three candidates were designed using similar 
algorithms and techniques which required little or no software modifications. Since the 
algorithms used by the candidates are very similar, the software requirements which drive the 
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algorithms tend to transcend a specific architecture, so that this design report may assume that 
any of the candidate architectures will be selected for implementation of the RPS. 

2. Applicable Documents 

The following is a list of the applicable documents. 


Document Name 

Date of Issue 

Revision 

Engineering Services Task (EST) Statement 
of Work E-8C RADAR Processor Simulation 



System Specification For Joint Surveillance 
Target Attack RADAR System 

AN/USY-TBD (JOINT STARS) 

21 December 1992 


Prime Item Development 

Specification For RADAR 

Subsystem AN/APY-(TBD) For 

Joint Surveillance Target 

Attack RADAR System (JOINT STARS) 

12 June 1991 


Architecture Design Report for the 

RADAR Processor Simulation for the 

Joint Surveillance Target 

Attack RADAR System (JOINT STARS) 

March 1996 


Standard for Distributive Interactive 
Simulation - Application Protocols 

Version 2.0.4 

16 March 1994 


Security Classification Guide 

Joint STARS 

Version 2.0.4 

9 March 1994 


Interface Control Document for the 

SAR Imagery Simulation of the Joint STARS 
Radar Processor Simulation 

TBD 
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3. Requirements 


The hardware and software requirements specific to the development of the RPS within Joint 
STARS will be presented in this section. 

3.1 Hardware Requirements 


This section presents the hardware requirements for the incorporation of the RPS into the Joint 
STARS system. Since one of the primary system design goals for the RPS is to limit if not 
eliminate, hardware modifications to the Joint STARS system, there are few hardware 
requirements placed on implementation of the RPS. Under normal conditions, the RPS shall [1] 
consist of two distinct architectures, one on the ground (3.1.3) interfacing with the DIS network, 
and one on-board the Joint STARS platform (3.1.4) performing the MTI and SAR Imagery 
simulations. These two architectures shall [2] be connected by an RF Link (3.1.2) during flight 
mode and with a LAN while in the lab environment. 

3.1.1 Joint STARS Configuration 

The RPS shall [3] be developed for incorporation into the third aircraft configuration used for 
low rate initial production of the E-8C Joint STARS. 

3.1.2 RF Link 


The bandwidth requirements for the RF Link will be developed during the detailed design phase 
of the RPS from message load tests with the assistance of the JADS JTF. 

3.1.3 Down Link Architecture 

The down link processes developed for the RPS will be hosted in a general purpose computer 
capable of processing the maximum PDU rates and capacities specified in 3.2 1 3 The down 
link architecture shall [4] be capable of logging PDUs for future data analysis and test purposes. 

3.1.4 Up Link Architecture 

The up link processes developed for the RPS shall [5] be hosted in one or more of the Joint 
STARS general purpose computers (GPC) on board the platform. The JADS Architectural 
Design Report identifies the RDP GPC, SPR GPC, and the ATWS as possible candidates for 
hosting the up link RPS architecture. 
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3.2 Software Requirements 

This section presents the software requirements for four functional levels of the system design; 
(1) RPS control; (2) MTI Simulation; (3) SAR Imagery Simulation; (4) and Stand Alone 
operations. 

3.2.1 RPS Control 

The RPS control function will provide the interface between the Joint STARS functions, the RPS 
functions and the external IADS environment. Within the RPS, the control function will provide 
the MTI (3.2.2) and SAR Imagery (3.2.3) simulation with the appropriate Joint STARS data and 
external JADS data to perform their functionality. 

3.2.1.1 Initialization 

The RPS will be initialized with the data described in this section. 

3.2.1.1.1 Identify Live AOIs 

A live area of interest (LAOI) is defined as a rectangular region of interest entirely located within 
the 512-by-512 Km primary region of interest. Within these LAOIs, only “live” targets detected 
by Joint STARS shall [6] be reported. Outside of these LAOIs, only “virtual” targets supplied to 
the RPS shall [7] be reported. The RPS shall [8] maintain up to four LAOIs. The set of LAOIs 
shall [9] be provided by the customer as a file to be read in upon initialization of the RPS and 
cannot be modified during the JADS exercise. 

3.2.1.1.2 Identify Hypso and Carto Database 

The hypsographic and cartographic databases defining the features of the Joint STARS primary 
region shall [10] be replaced upon initialization of the RPS with a new set of databases 
incorporating the virtual features for the JADS mission. These databases will be the same format 
as those used for the Joint STARS mission and will be supplied by the customer. For SAR 
Imagery, a SAR features database will be developed and supplied by the customer. 

3.2.1.2 Operator Controls 

The RPS operator shall [11] be given modest control of simulation parameters through the use of 
flags and thresholds. The set of modifiable parameters will be at least, but not limited to the 
following; 

• Enable / Disable MTI Pd 

- If enabled, minimum and maximum Pd. (Pd = 1 if disabled) 
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Enable / Disable MTI CEP 


- If enabled, maximum down range and cross range error. (CEP = 0 if disabled) 

• Enable / Disable MTI Terrain Screening 

• Enable / Disable MTI False Alarms 

• Weather conditions as Clear, Cloud, or Rain 

• Joint STARS Entity State (ES) Protocol Data Unit (PDU) Heartbeat Period 

• Joint STARS ES PDU Platform Position Update Threshold 
3.2.1.3 DIS Interface Control 


The RPS control function shall [12] receive ES PDUs over the DIS network and maintain a 
database of those ES PDUs applicable to the Joint STARS mission. 

3.2.1.3.1 DIS Network 

ES PDUs shall [13] be managed in two separate architectures, one on the ground connected to 
the DIS network, referred to as DISNIU I, and a second on the platform connected to the Joint 
STARS OWS and / or PSP LAN, referred to as DISNIU H. When operating in flight mode, they 
will be connected by an RF link. When operating in a lab environment, they will be connected 

with a LAN. DISNIU I shall [14] use the TCP/IP UDP protocol for communication on the DIS 
network. 

3.2.1.3.2 Receive Entity State PDUs 

The Entity State (ES) Protocol Data Unit (PDU) is the primary type required to be acted upon by 
the RPS. ES PDUs contain information about a particular entity as described in the DIS standard 
(2.). An entity can be any object such as a tank, a truck, an aircraft, a bridge, a building, etc..., 
and is considered a virtual target by the RPS. The RPS will receive new ES PDUs by the war- 
games simulation, followed by a periodic “heartbeat” ES PDU for each entity to affirm reception 
by the RPS. Virtual target updates will be received by the RPS via ES PDUs when the position 
of the virtual target has exceeded the pre-determined threshold based on dead reckoning 
(3.2.1.3.5) updates by the war-games simulation. The RPS shall [15] be required to maintain at 
least 5000 virtual targets, with a growth capacity of at least 20000 virtual targets. Virtual targets 
shall [16] be deleted by the RPS when the war-games simulation issues a Remove Entity PDU or 
if “deactivated” by an ES PDU. 
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3.2.1.3.3 Coordinate Conversion 


ES PDUs received over the DIS network contain position and velocity information in the Earth- 
Centered-Earth-Fixed (ECEF) coordinate system using the 1984 World Geographic System earth 
model (WGS-84). ES PDU position and velocity shall [17] be converted from ECEF to the Joint 
STARS Topocentric Coordinate System (TCS) by SIDNIU I in order to save processor load for 
the real-time MTI (3.2.2) and SAR Imagery (3.2.3) simulations on the platform. ES PDU 
orientation shall [18] be converted from the entity coordinate system to TCS by DISNIU I. 

3.2.1.3.4 Filter Entity State PDUs 

ES PDU information applicable to the MTI and SAR Imagery simulations shall [19] be reduced 
to the minimum amount of information required by the real-time simulations in order to 
minimize the use of the available RF Link bandwidth. As a minimum, the ES PDUs will be 
reduced to a virtual entity described by its unique identifier, entity type, time tag, position, 
velocity, orientation, and appearance. Currently, ES PDUs will be received from a single source, 
so that identification of each ES PDU may be accomplished using a unique entity ID (SITE = 
APPLICATION). The software design should accommodate multiple sites and applications as a 
growth provision. 

ES PDU filtering shall [20] be performed on a maximum sustained rate of 100 virtual target 
updates per second plus the heartbeat rate. After DISNIU I has coordinate converted and reduced 
the ES PDU to its minimum length, the virtual target updates will be sent up the RF Link to the 
DISNIU n. If the currently undefined RF Link bandwidth cannot support the virtual target 
update rate, then further data compression may be required along with a geometrical filter placed 
around existing RSR AOIs to reducr the number of virtual target updates sent over the RF Link. 
If a geometrical filter is necessary, the virtual target dead reckoning (3.2.1.3.5) will also be 
required in DISNIU I. 

3.2.1.3.5 Dead Reckoning 

Virtual targets received by DISNIU n shall [21] be extrapolated to current time at a minimum 
rate of 5 Hz using a first order position update (P = Pq + VAT). Timing studies in the 
Architectural Design Report indicate that first order target dead reckoning does not adversely 
effect the radar timeline even when the number of targets exceeds the current virtual target 
capacity. Dead reckoned virtual targets will be make available to the MTI (3.2.2) and SAR 
Imagery (3.2.3) simulations. 

3.2.1.3.6 Joint STARS Entity State PDU 

DISNIU n will send state information about the Joint STARS Platform, including position and 
velocity, down the RF Link to DISNIU I, which will be converted to an ES PDU and output over 
the DIS network. The Joint STARS state message shall [22] be sent at a 1 Hz rate by DISNIU n 
and output over the DIS network by DISNIU I when the dead reckoned platform position varies 
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by more than the operator specified Joint STARS position threshold, or its heartbeat timer has 
expired. 

3.2.1.4 Live Target Control 

The RPS will provide the MTI Simulation (3.2.2) those targets detected by the Joint STARS 
radar for the current radar beam dwell. Depending upon the architecture selected, these “live” 
targets may be provided as threshold crossings on a coherent processing interval (CPI) basis or 
as associated targets on a beam dwell basis. 

3.2.2 MU Simulation 


The MTI simulation will receive as input from the RPS control function (3.2.1) the current beam 
dwell s live targets and the moving virtual targets received form the DIS interface. The virtual 
targets shall [23] be geometrically filtered, have MTI statistics applied, and mixed with the 
appropriate live targets for output from the radar subsystem. The processing required by the MTI 
simulation shall [24] not degrade the radar timeline beyond the nominal timeline fluctuations 
expenenced by the Joint STARS radar under heavy target load conditions. 

3.2.2.1 MTI Control 


The MTI control function shall [25] determine those virtual 
dwell footprint but not within the LAOIs. 


targets within the current beam 


3.2.2.1.1 Reverse Area Blanking 

For each radar coherent processing interval (CPI), those range bins which interact one or more of 

^,'1 consideration of live targets. Range bins which do not intersect 

an LAOI will be identified for consideration of virtual targets. 

3.2.2.1.2 Beam Dwell Footprint 

For each radar beam dwell, a beam footprint will be determined from the initial cone angle, range 
coverage, and beamwidth parameters provided in the radar AUX data. The radar AUX data is 
available within several messages throughout the radar subsystem. The beam footprint will be 
approximated as a quadrilateral in the Topocentric Coordinate System (TCS) for easy 
comparison with live and virtual targets already defined in TCS. For each Radar Service Request 
(RSR) actively being scanned, the beam dwell footprints will be contiguously maintained without 
overlap until a start of revisit, start of swath, or a resumption of revisit condition occurs for 
which a complete footprint must be computed. 

3.2.2.1.3 Filter Live Targets 

Targets detected by the Joint STARS radar will be considered “live” targets. Only those live 
targets which reside inside a LAOI shall [26] be considered “detected” by the RPS. All live 
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targets which reside outside the LAOIs (aka virtual area) will not be considered a detected target 
by the RPS. Live targets being filtered on a CPI basis will only be considered if they fall within 
the LAOI range bins determined in reverse area blanking (3.2.2.1.1). 

3.2.2.1.4 Filter Virtual Targets 

Moving targets within the entity database will be considered “virtual” targets. Only those virtual 
targets which reside outside the LAOIs (aka virtual area) and within the current radar beam dwell 
footprint shall [27] be considered for possible “detection” by the RPS. The MTI processing 
(3.2.2.2) function will determine which virtual targets will actually by detected. Timing studies 
in the Architectural Design Report indicate that virtual target filtering for conditions exceeding 
the current virtual target capacity adversely effects the radar timeline. For these conditions, a 
grid filtering technique shows some promise for reducing the radar timeline to a manageable 
level. The grid filtering technique requires the virtual targets to be pre-sorted into a series of X-Y 
grids which can be quickly checked against the radar beam footprint, thereby quickly eliminating 
a significant number of virtual targets from consideration. The goal of this tradeoff wouldbe to 
define the grid size to minimize the number of grids plus targets to check against the radar beam 
footprint and minimize the management overhead of the grid structure. 

3.2.2.1.5 Mix Live and Virtual Targets 

For each radar beam dwell, the detected live moving targets (3.2.2.1.3) and the detected virtual 
moving targets (3.2.2.2) shall [28] be merged into a single dwell report representing a mix of live 
and virtual targets within the same beam, but not overlapping in physical space. Depending upon 
the selected architecture, this functionality may be achieved prior to, or after, target association 
occurs within the RDO post processing function. 

3.2.2.2 MTI Processing 

After the MTI control function (3.2.2.1) filters the virtual targets based on beam dwell and LAOI 
geometry, this simulation shall [29] create a subset of these virtual targets which exhibit similar 
characteristics as live Joint STARS targets would under the same scan conditions. These virtual 
targets will have moving target indicator statistics applied and will be output to the MTI control 
function to be mixed with the appropriate live targets detected in the same beam. 

3.2.2.2.1 Beam Dwell 

The radar beam’s range coverage, azimuth, and 3dB dwell time will be derived for each beam 
dwell from the radar AUX data. The radar beam’s range coverage extends the specified number 
of range bins from the range start value adjusted by the radar zero range delay and range 
refraction correction. The radar beam azimuth coverage is defined by the cosine cone angle term 
and the specified beam spacing. The radar dwell time is derived from the radar pulse repetition 
interval (PRI), the number of integrated pulses, and the waveform identifier. Since the Joint 
STARS radar uses variable beam spacing, the dwell time will be normalized to the 3dB spacing 


B- 15 




using the azimuth angle and the actual beam spacing commanded. The waveform identifier 
indicates the PRFs used in the beam dwell. 

3.2.2.2.2 Environmental Conditions 


Applicable external environmental conditions will be considered to effectively model 
targets. 


moving 
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3.2.2.2.2.1 Weather 


Weather conditions shall [30] be assumed to be one of three categories; (1) clear; (2) cloud; (3) 
rain; as defined in the Joint STARS System Specification, as selected by the JADS operator 
(3.2.1.2). Future considerations should be made for incorporation of weather PDUs defining 
regions of weather coverage. From the selected weather condition, an additional signal-to-noise 
(S/N) variation over the range coverage will be computed for use by the Pd (3.2.2.2.3.5) and 
location accuracy (3.2.2.2.3.3) functions. The additional S/N loss will be determined based on 
the Joint STARS System Specification losses for each weather condition. 

3.2.2.2.2.2 Refraction 

A range refraction curve will be derived for the range coverage of each beam dwell and applied 
to the down range target statistics for location accuracy (3.2.2.2.3.3). The method employed by 
Joint STARS to determine the range refraction correction shall [31] be used by the RPS to 
enhance symmetry between live and virtual targets. 

3.2.2.2.2.3 Terrain 

The RPS shall [32] identify those virtual targets obscured by terrain based on the hypsographic 
database, and the current platform position along the radar beam’s line of sight. As indicated in 
figure 3.2-1, when the elevation of the target to the platform is less than the elevation of the 
target to the highest grid point along the beam’s line of sight, then that target is considered 
screened by the terrain and not eligible for detection. 
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3 . 2 . 2.23 Virtual Target Statistics 

MTI statistics shall [33] be applied stochastically to the virtual targets using a uniformly 
distributed random number sequence in order to effectively simulate virtual targets as Joint 
STARS targets. All virtual target statistics will be derived from a single random number seed. 

3.2.2.2.3.1 Virtual Target Geometry 

The Control function (3.2.2.1) will provide those virtual targets to be considered for MTI 
processing. These targets have been dead reckoned to the current beam dwell time and as a 
minimum are represented by its target position (P,) and velocity (Vj) vectors in TCS. Pt and Vt 
represent the ground truth of the target for which MTI statistics will be applied. Each target’s 
ground truth will be converted to radar coordinates of range, azimuth, and radial velocity. 

3.2.2.2.3.2 Radar Cross Section 

The RPS will use a nominal sized target defined in the Joint STARS System Specification. 
Virtual target amplitudes will vary as a function of range with random fluctuations within a 5dB 
tolerance interval. 

3.2.2.2.3.3 Location Accuracy 

Target location accuracy is measured using the Circular Error Probable (CEP) method with 
separate down and cross range errors assumed to be uncorrelated forming a linear error model 
shown in figure 3.2-2. S/N variations due to weather and range will be modeled for 
determination of the one sigma cross range component in the linear model. Amplitude and 
frequency modulation techniques will be applied to the mean and one sigma error statistics to 
prevent integrated targets from looking too “simulation-like”. These modulation techniques have 
the effect of moving a smaller CEP circle within a larger CEP circle to achieve the same CEP 
results with fewer unrealistic random fluctuations. Once the down range and cross range error 
has been established, these values shall [34] be applied to the position vector (Pt) of the target. 
The down range error is applied in the TCS X-Y plane along the beam’s line of sight to the 
target, while the cross range error is applied perpendicular to the beam’s line of sight to the 
target. 
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CM 3-2-2.CEP.pl 



Figure 3.2-2. Circular Error Probable (CEP) 


3.2.2.2.3.4 Target Resolution 

Multiple targets located within the same range / doppler cell cannot be distinguished from each 
other, so that Joint STARS range, velocity and angle resolution constraints will be applied to 
target detection statistics. If multiple targets cannot be distinguished, then only one target may be 
detected. 

3.2.2.2.3.5 Probability of Detection (Pd) 

The average Pd of a target (Pd,) is fundamentally related to target S/N as derived from the radar 
range equation. The Joint STARS radar is designed to compensate for two major S/N factors in 
real time by varying the radar beam dwell time as a function of azimuth and range. These S/N 
factors are azimuth beam broadening losses resulting from steering the beam electronically in 
azimuth, and target range loss. Radar operating curves (3.2.2.2.4) shall [35] be developed off 
line which relate the radar beam dwell time to the Joint STARS azimuth (figure 3.2-3) and range 
(figure 3.2-4) constraints for a family of Pd and S/N levels. Analysis has shown that these curves 
are reasonably well behaved and can be modeled using a Lagrange interpolation series of four 
points. 

The Lagrange interpolation coefficients can be expanded in azimuth and range to derive the 
theoretical 3dB dwell times for various average Pd levels, from which Pd, can be interpolated 
based on the actual 3dB dwell time produced by the radar scan. This technique effectively 
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reverses the Joint STARS engineering process of solving for dwell time given a desired Pd. 
Once Pd, is found, radial velocity dips due to PRF blinds will be applied. The RPS shall [36] 
have a Pd versus radial velocity curve (figure 3.2-5) for each waveform identifier developed off 
line as per section (3.2.2.2.4). Since the structure of the radial velocity dips do not change for 
various Pd levels, the actual target Pd (Pd,) will be determined for Pd, and the Pd versus radial 
velocity curve, by effectively moving the curve up or down so that its average Pd is the same as 
Pd,. The radial velocity Pd dips are attenuated when increasing the average Pd and enhanced 
when reducing the average Pd through use of a range rate dip factor (R^). 

As a minimum, virtual target Pd (Pd,) shall [37] be derived from the following information: 

• Scan conditions (3.2.2,2.1) 

- Azimuth : expand dwell time by azimuth, figure 3.2-3. 

- Range coverage : expand dwell time by range, figure 3.2-4. 

- 3dB beam dwell time : apply Pd factor to dwell time, figure 3.2-5. 

- Waveform identifier; select nominal Pd vs Velocity curve, figure 3.2-6. 

• Environmental factors (3.2,2.2.2) 

- Weather loss : interpolate Lagrange coefficients between S/N levels. 

- Terrain : targets obscured by terrain cannot be detected (Pd = 0). 

• Virtual target geometry (3.2.2.2.3.1) 

- Azimuth : for Pd purposes, target azimuth may be assumed to be the same as 
beam dwell azimuth, since the azimuth beamwidth is relatively small. 

- Range . solve for dwell time based on range coverage curve, figure 3.2-4. 

- Radial velocity : Pd, = Pd, + Rf x (Pd,, - Pdr) 

* Pd, is the Pd of the virtual target at radial velocity V. 

* Pd, is the Pd of the virtual target averaged over all radial velocities. 

* Rf is the range rate factor used to attenuate / enhance Pd dips. 

* Pdr, is the Pd of the reference curve at radial velocity V. 

* Pdr is the Pd of the reference curve averaged over all radial velocities. 

• Target resolution (3.2,2.2.3.4) 
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3DB DWELL TIME (SEC) 



SCfiN ANGLE (DEG) 


Figure 3.2-3. Expand Dwell Time by Azimuth (at Minimum Range) 



RANGE (ICM) 


Figure 3.2-4. Expand Dwell Time by Range (at Dwell Azimuth) 
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3-2-SJWCT.PL 



Figure 3.2-5. Apply Pd Factor to Dwell Time 



Figure 3.2-6. Apply Radial Velocity Dips 

3.2.2.2.3.6 Probability of False Alarm (PFA) 

RSR receiver threshold levels shall [38] be considered to increase or decrease the nominal PFA 
required by the Joint STARS System Specification. False virtual targets will be placed randomly 
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in range and azimuth within the radar beam dwell (3.2.2.2.1) after all virtual targets have been 
considered. 

3.2.2.23.1 Target Classification (TC) 

A TC of wheeled or tracked will be determined based on the probability of detecting the double 
doppler component. Since the double doppler component is significantly smaller than the actual 
target, determination of virtual target TC shall [39] be accomplished like Pd (3.2.2.2.3.5) such 
that TC represents an additional S/N loss. Virtual target TC results will be applied after PSP 
Node 2 processing has been completed. 

3.2.2.2.4 Modeling 

A set of radar operating curves shall [40] be developed for the real-time MTI Simulation which 
relates MTI Pd (3.2.2.2.3.5) and CEP (3.2.2.2.3.3) statistics as a fuction of target S/N. These 
curves will be developed primarily from non-real-time Joint STARS simulations and tempered 
by empirical results obtained through flight test conditions. This approach enables the real-time 
MTI simulation to emulate the statistical tendencies of the Joint STARS radar over the infinite 
set of possible scan conditions encountered in the real world. The radar operating curves will be 
developed under baseline conditions of clear weather (3.2.2.2.2.1), for a nominal sized target 
(3.2.2.2.3.2), from which S/N variations will be interpolated. 

3.2.3 SAR Imagery Simulation 

The SAR Imagery simulation shall [41] receive as input from the RPS Control function (3.2.1) 
the SAR beam dwell data and the stationary virtual targets received over the DIS network. The 
stationary virtual targets will be geometrically filtered, modeled according to Joint STARS SAR 
resolution capabilities and mixed with the virtual terrain features within the SAR features 
database. Requests for SAR or FTI service shall [42] be considered a virtual SAR/FTI request if 
the central reference point (CRP) defining the SAR/FTI AOI falls within the virtual area. FTI 
processing will be a thresholded version of SAR Imagery processing. 

3.2.3.1 SAR Imagery Control 

*** TBD pending LORAL contract status*** 

3.2.3.2 SAR Imagery Processing 

*** TBD pending LORAL contract status*** 

3.2.4 Stand Alone Mode 

The RPS shall [43] be capable of executing in a simulation only mode, referred to as the Stand 
Alone mode, such that the RPS functions in the same manner as during flight mode, but without 
live data inputs. This mode requires all Joint STARS PME except those contained in the radar 
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sensor group (RSG), Propammable Signal Processors (PSP), and the Navigation subsystem. 
The interfaces with the missing PME will be simulated in real-time as defined in the following 
subsections. 

3.2.4.1 Radar Control Simulation 

The radar AUX data containing sensor commands used by the radar during each CPI shall [44] 
be simulated based upon the commands given in the Primary Mode Control (PMC) message sent 
by the RDP for each radar beam dwell. All other messages normally sent to or from the Radar 
Control Unit (RCU) on the 1553 Radar Sensor Bus (RSB) will be modeled for nominal 
conditions without errors induced. Radar Sensor IQ outputs will not be modeled. 

3.2.4.2 PSP Simulation 


The PSP setup / acknowledge, node 1 and node 2 communication paths with the RDP on the PSP 
LAN shall [45] be modeled based on the RDP inputs. No live targets or discretes will be 
simulated, and a nominal clutter environment will be used. All other messages normally sent to 
or from the PSP on the PSP LAN will be modeled for nominal conditions without errors induced. 
Radar sensor IQ inputs will not be modeled. 

3.2.4.3 Navigation Simulation 

The navigation data normally produced by the Joint STARS FMP CPCI Relative Navigation 
function shall [46] be simulated by the RPS. The navigation data contains platform position, 
velocity and attitude data as a function of time, and is output at a 10 Hz rate. The Navigation 
simulation will support a racetrack, figure eight, random, or circular orbit based on the contents 
of a navigation simulation file provided upon initialization of the RPS. 
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4. Quality Assurance 


The contractor will be responsible for maintaining the RPS software under a configuration 
management system comparable with that developed for Joint STARS. The contractor will be 
responsible for verification of the RPS requirements and for justifying the selected methods of 
verification. The contractor will formulate a separate verification and validation plan for the E- 
8C RPS. The methods of verification will be by inspection, analysis, demonstration, or test. 


B-25 



5. Definitions 


Provided in this section is a summary of acronyms used in this report. 


• AOI: Area of Interest 

• ATWS : Advanced Tactical Work Station 

• CEP : Circular Error Probable 

• CPI: Coherent Processing Interval 

• DIS : Distributed Interactive Simulation 

• DISNIU ; DIS Network Interface Unit 

• ECEF: Earth Centered Earth Fixed 

• ES PDU : Entity State Protocol Data Unit 

• GPC : General Purpose Computer 

• Joint STARS : Joint Surveillance Target Attack Radar System 

• LAN : Local Area Network 

• LAOI: Live AOI 

• MTI: Moving Target Indicator 

• PFA : Probability of False Alarm 

• Pd : Probability of Detection 

• PSP : Programmable Signal Processor 

• RCU : Radar Control Unit 

• RDO : Radar Data Operational 

• RDP : Radar Data Processor 

• RPS : Radar Processor Simulation 

• RSB : Radar Sensor Bus 

• RSG : Radar Sensor Group 

• RSR : Radar Service Request 

• S / N : Signal-to-Noise Ration 

• SAR : Synthetic Aperture Radar 

• TC : Target Classification 

• TCS : Topocentric Coordinate System 

• WAN : Wide Area Network 

• WGS-84 : World Geographic System 1984 
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References 


[1] 3.1. Hardware Requirements. Inspection. Under normal conditions, the RPS shall consist 
of two distinct architectures, one on the ground (3.1.3) interfacing with the DIS network, and 
one on-board the Joint STARS platform (3.1.4) performing the MTI and SAR Imagery 
simulations. 

[2] 3.1. Hardware Requirements. Demonstration. These two architectures shall be connected 
by an RF Link (3.1.2) during flight mode and with a LAN while in the lab environment. 

[3] 3.1.1. Joint STARS Configuration. Inspection. The RPS shall be developed for 
incorporation into the third aircraft configuration used for low rate initial production of the E- 
8C Joint STARS. 

[4] 3.1.3. Down Link Architecture. Test. The down link architecture shall be capable of 
logging PDUs for future data analysis and test purposes. 

[5] 3.1.4. Up Link Architecture. Inspection. The up link processes developed for the RPS shall 
be hosted in one or more of the Joint STARS general purpose computers (GPC) on board the 
platform. 

[6] 3.2.1.1.1. Identify Live AOIs. Test. Within these LAOIs, only “live” targets detected by 
Joint STARS shall be reported. 

[7] 3.2.1.1.1. Identify Live AOIs. Test. Outside of these LAOIs, only “virtual” targets supplied 
to the RPS shall be reported. 

[8] 3.2.1.1.1. Identify Live AOIs. Demonstration. The RPS shall maintain up to four LAOIs. 

[9] 3.2.1.1.1. Identify Live AOIs. Inspection. The set of LAOIs shall be provided by the 
customer as a file to be read in upon initialization of the RPS and cannot be modified during 
the JADS exercise. 

[10] 3.2.1.1.2. Identify Hypso and Carto Database. Inspection. The hypsographic and 
cartographic databases defining the features of the Joint STARS primary region shall be 
replaced upon initialization of the RPS with a new set of databases incorporating the virtual 
features for the JADS mission. 

[11] 3.2.I.2. Operator Controls. Test. The RPS operator shall be given modest control of 
simulation parameters through the use of flags and thresholds. 

[12] 3.2.1.3. DIS Interface Control. Inspection. The RPS control function shall receive ES 
PDUs over the DIS network and maintain a databac^ of those ES PDUs applicable to the 
Joint STARS mission. 
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[13] 3.2.1.3.1. DIS Network. Inspection. ES PDUs shall be managed in two separate 
architectures, one on the ground connected to the DIS network, referred to as DISNIU I, and a 
second on the platform connected to the Joint STARS OWS and/or PSP LAN, referred to as 
DISNIU n. 

[14] 3.2.I.3.I. DIS Network. Inspection. DISNIU I shall use the TCP/IP UDP protocol for 
communication on the DIS network. 

[15] 3.2.1.3.2. Receive Entity State PDUs. Inspection. The RPS shall be required to maintain at 
least 5000 virtual targets, with a growth capacity of at least 20000 virtual targets. 

[16] 3.2.1.3.2. Receive Entity State PDUs. Test. Virtual targets shall be deleted by the RPS 
when the war-games simulation issues a Remove Entity PDU or if “deactivated” by an ES 
PDU. 

[17] 3.2.1.3.3. Coordinate Conversion. Inspection. ES PDU position and velocity shall be 
converted from ECEF to the Joint STARS Topocentric Coordinate System (TCS) by DISNIU 
I in order to save processor load for the Real-time MTI (3.2.2) and SAR Imagery (3.2.3) 
simulations on the platform. 

[18] 3.2.1.3.3. Coordinate Conversion. Inspection. ES PDU orientation shall be converted from 
the entity coordinate system to TCS by DISNIU I. 

[19] 3.2.1.3.4. Filter Entity State PDUs. Analysis. ES PDU information applicable to the MTI 
and SAR Imagery simulations shall be reduced to the minimum amount of information 
required by the real-time simulations in order to minimize the use of the available RF Link 
bandwidth. 

[20] 3.2.1.3.4. Filter Entity State PDUs. Test. ES PDU filtering shall be performed on a 
maximum sustained rate of 100 virtual target updates per second plus the heartbeat rate. 

[21] 3.2.I.3.5. Dead Reckoning. Inspection. Virtual targets received by DISNIU n shall be 
extrapolated to current time at a minimum rate of 5 Hz using a first order position update (P 
= Po + VAT). 

[22] 3.2.1.3.6. Joint STARS Entity State PDU. Test. The Joint STARS state message shall be 
sent at a 1 Hz rate by DISNIU n and output over the DIS network by DISNIU I when the 
dead reckoned platform position varies by more than the operator specified Joint STARS 
position threshold, or its heartbeat timer has expired. 

[23] 3.2.2. MTI Simulation. Test. The virtual targets shall be geometrically filtered, have MTI 
statistics applied, and mixed with the appropriate live targets for output from the radar 
subsystem. 
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[24] 3.2.2. MTI Simulation. Test. The processing required by the MTI simulation shall not 
degrade the radar timeline beyond the nominal timeline fluctuations experienced by the Joint 
STARS radar under heavy target load conditions. 

[25] 3.2.2.1. MIT Control. Inspection. The MTI control function shall determine those virtual 
targets within the current beam dwell footprint but not within the LAOIs. 

[26] 3.2.2.1.3. Filter Live Targets. Test. Only those live targets which reside inside a LAOI 
shall be considered “detected” by the RPS. 

[27] 3.2.2.1.4. Filter Virtual Targets. Test. Only those virtual targets which reside outside the 
LAOIs (aka virtual area) and within the current radar beam dwell footprint shall be 
considered for possible “detection” by the RPS. 

[28] 3.2.2.1.5. Mix Live and Virtual Targets. Demonstration. For each radar beam dwell, the 
detected live moving targets (3.2.2.1.3) and the detected virtual moving targets (3.2.2.2) shall 
be merged into a single dwell report representing a mix of live and virtual targets within the 
same beam, but not overlapping in physical space. 

[29] 3.2.2.2. MTI Processing. Demonstration. After the MTI control function (3.2.2.1) filters 
the virtual targets based on beam dwell and LAOI geometry, this simulation shall create a 
subset of these virtual targets which exhibit similar characteristics as live Joint STARS 
targets would under the same scan conditions. 

[30] 3.2.2.2.2.I. Weather. Inspection. Weather conditions shall be assumed to be one of three 
categories; (1) clear; (2) cloud; (3) rain; as defined in the Joint STARS System Specification, 
as selected by the JADS operator (3.2.1.2). 

[31] 3.2.2.2.2.2. Refraction. Inspection. The method employed by Joint STARS to determine 
the range refraction correction shall be used by the RPS to enhance symmetry between live an 
virtual targets. 

[32] 3.2.2.2.2.3 Terrain. Test. The RPS shall identify those virtual targets obscured by terrain 
based on the hypsographic database, and the current platform position along the radar beam’s 
line of sight. 

[33] 3.2.2.23. Virtual Target Statistics. Inspection. MTI statistics shall be applied 
stochastically to the virtual targets using a uniformly distributed random number sequence in 
order to effectively simulate virtual targets as Joint STARS targets. 

[34] 3.2.2.2.3.3. Location Accuracy. Test. Once the down range and cross range error has beep 
established, these values shall be applied to the position vector (Pt) of the target. 


B-29 



[35] 3.2.2.2.3.5. Probability of Detection (Pd). Analysis. Radar operating curves (3.2.2.2.4) 
shall be developed off line which relate the radar beam dwell time to the Joint STARS 
azimuth (figure 3.2-3) and range (figure 3.2-4) constraints for a family of Pd and S / N levels. 

[36] 3.2.2.2.3.5. Probability of Detection (Pd), Analysis. The RPS shall have a Pd versus radial 

velocity curve (figure 3.2-5) for each waveform identifier developed off line as per section 
( 3 . 2 . 2.2 » 4 ). 

[37] 3.2.2.2.3.5. Probability of Detection (Pd). Test. As a minimum, virtual target Pd (PdJ shall 
be derived from the following information; Scan conditions (3.2.2.2.1), Environmental 
factors (3.2.2.2.2), Virtual target geometry (3.2.2.2.3.1), and Target resolution (3.2.2.2.3.4). 

[38] 3.2.2.2.3.6. Probability of False Alarm (PFA). Test) RSR receiver threshold levels shall be 

considered to increase or decrease the nominal PFA required by the Joint STARS System 
Specifications. ^ 

[39] 3.2.2.2.3.7. Target Classification (TC). Analysis. Since the double doppler component is 
significantly smaller than the actual target, determination of virtual target TC shall be 
accomplished like Pd (3.2.2.2.3.5) such that TC represents and additional S / N loss. 

[40] 3.2.2.2.4. Modeling. Analysis. A set of radar operating curves shall be developed for the 
real-time MTI Simulation which relates MTI Pd (3.2.2.2.3.5) and CEP (3.2.2.2.3 3) statistics 
as a function of target S / N. 

[41] 3.2.3. Sar Imagery Simulation. Demonstration. The SAR Imagery simulation shall receive 
as input from the RPS Control function (3.2.1) the SAR beam dwell data and the stationary 
Virtual targets received over the DIS network. 

[42] 3.2.3. SAR Imagery Simulation. Test. Requests for SAR or FTI service shall be considered 
a virtual SAR / FTI request if the central reference point (CRP) defining the SAR / FTI AOI 
falls within the virtual area. 

[43] 3.2.4. Stand Alone Mode. Demonstration. The RPS shall be capable of executing in a 
simulation only mode, referred to as the Stand Alone mode, such that the RPS functions in 
the same manner as during flight mode, but without live data inputs. 

[44] 3.2.4.1. Radar Control Simulation. Demonstration. The radar AUX data containing sensor 
commands used by the radar during each CPI shall be simulated based upon the commands 

given in the Primary Mode Control (PMC) message sent by the RDP for each radar beam 
dwell. 


[45] 3.2.4.2. PSP Simulation. Demonstration. The PSP setup / acknowledge, node 1 and node 2 

communication paths with the RDP on the PSP LAN shall be modeled based on the RDP 
inputs. 
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[46]3.2.4.3. Navigation Simulation. Demonstration. The navigation data normally produced by 
the Joint STARS FMP CPCI Relative Navigation function shall be simulated by the RPS. 
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PRELIMINARY 

Verification Cross Reference Matrix (VCRM) 


Item 

Paragraph 

Paragraph Title 

Method 

Requirement 

1 

3.1 

Hardware Requirements 

Inspection 

Under normal conditions, the RPS shall 
consist of two distinct architectures, one on 
the ground (3.1.3) interfacing with the DIS 
network, and one on-board the Joint 

STARS platform (3.1,4) performing the 

MTI and SAR Imagery simulations 

2 

3.1 

Hardware Requirements 

Demonstration 

These two architectures shall be connected 
by an RF Link (3.1.2) during flight mode 
and with a LAN while in the lab 
environment. 

3 

3.1.1 

Joint STARS Configuration 

Inspection 

The RPS shall be developed for 
incorporation into the third aircraft 
configuration used for low rate initial 
production of the E-8C Joint STARS 

4 

3.1.3 

Down Link Architecture 

Test 

The down link architecture shall be capable 
of logging PDUs for future data analysis 
and test purposes. 

5 

3.1.4 

Up Link Architecture 

Inspection 

The up link processes developed for the 

RPS shall be hosted in one or more of the 
Joint STARS general purpose computers 
(GPC) on board the platform 

6 

3.2.1.1.1 

Identify Live AOIs 

Test 

Within these LAOIs, only “live” targets 
detected bv Joint STARS shall be reported 

7 

3.2.1.1.1 

Identify Live AOIs 

Test 

Outside of these LAOIs, only “virtual” 
targets supplied to the RPS shall be 
reported. 

8 

3.2.1.1.1 

Identify Live AOIs 

Demonstration 

The RPS shall maintain up to four LAOIs. 

9 

3.2.1.1.1 

Identify Live AOIs 

Inspection 

The set of LAOIs shall be provided by the 
customer as a file to be read in upon 
initialization of the RPS and cannot be 
moditied during the JADS exercise. 

10 

3.2.1.1.2 

Identify Hypso and Carto 
Database 

Inspection 

The hypsographic and cartographic 
databases defining the features of the Joint 
STARS primary region shall be replaced 
upon initialization of the RPS with a new 
set of databases incorporating the virtual 
features for the JADS mission. 

11 

3.2.1.2 

Operator Controls 

Test 

The RPS operator shall be given modest 
control of simulation parameters through 
the use of flaes and threshnlHc 

------B —• --_I 
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Item 


Paragraph Title 

Method 

Requirement 

12 

3.2.1.3 

DIS Interface Control 

Inspection 

The RPS control function shall receive ES 
PDUs over the DIS network and maintain a 
database of those ES PDUs applicable to 
the Joint STARS mission. 

13 

3.2.1.3.1 

DIS Network 

Inspection 

ES PDUs shall be managed in two separate 
architectures, one on the ground connected 
to the DIS network, referred to as DISNIU 

I, and a second on the platform connected to 
the Joint STARS OWS and/or PSP LAN, 
referred to as DISNIU II. 

14 

3.2.1.3.1 

DIS Network 

Inspection 

DISNIU I shall use the TCP/IP UDP 
protocol for communication on the DIS 
network. 

15 

3.2.1.3.2 

Receive Entity State PDUs 

Inspection 

The RPS shall be required to maintain at 
least 5000 virtual targets, with a growth 
capacity of at least 20000 virtual targets. 

16 

3.2.1.3.2 

Receive Entity State PDUs 

Test 

Virtual targets shall be deleted by the RPS 
when the war-games simulation issues a 
Remove Entity PDU or if “deactivated” by 
an ES PDU. 

17 

3.2.1.3.3 

Coordinate Conversion 

Inspection 

ES PDU position and velocity shall be 
converted from ECEF to the Joint STARS 
Topocentric Coordinate System (TCS) by 
DISNIU I in order to save processor load 
for the Real-time MTI (3.2.2) and SAR 
Imagery (3.2.3) simulations on the platform. 

18 

3.2.L3.3 

Coordinate Conversion 

Inspection 

ES PDU orientation shall be converted from 
the entity coordinate system to TCS by 
DISNIU I. 

19 

3.2.1.3.4 

Filter Entity State PDUs 

Analysis 

ES PDU information applicable to the MTI 
and SAR Imagery simulations shall be 
reduced to the minimum amount of 
information required by the real-time 
simulations in order to minimize the use of 
the available RF Link bandwidth. 
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Item 


20 I 3.2.1.3.4 


21 I 3.2.L3.5 


22 I 3.2.1.3.6 


Paragraph Title 


Filter Entity State PDUs 


Dead Reckoning 


Joint STARS Entity State PDU 


Method 


Test 


Inspection 






MTI Simulation 


MTI Simulation 





26 I 3.2.2.L3 


27 I 3.2.2.1.4 


MTI Control 


Filter Live Targets 


Filter Virtual Targets 


Inspection 


28 I 3.2.2.1.5 



Mix Live and Virtual Targets I Demonstration 





Demonstration 


__ Requirement 


ES PDU filtering shall be performed on a 
maximum sustained rate of 100 virtual 
target updates per second plus the heartbeat 
rate. 


Virtual targets received by DISNIUII shall 
be extrapolated to current time at a 
minimum rate of 5 Hz using a first order 
osition update (P = Pn + VATl. 


The Joint STARS state message shall be 
sent at a 1 Hz rate by DISNIU II and output 
over the DIS network by DISNIU I when 
the dead reckoned platform position varies 
by more than the operator specified Joint 
STARS position threshold, or its heartbeat 
timer has expired. 


The virtual targets shall be geometrically 
filtered, have MTI statistics applied, and 
mixed with the appropriate live targets for 
output from the radar subsvstem. 


The processing required by the MTI 
simulation shall not degrade the radar 
timeline beyond the nominal timeline 
fluctuations experienced by the Joint 
STARS radar under heavy target load 
conditions. 


The MTI control function shall determine 
those virtual targets within the current beam 
dwell footprint but not within the LAOIs. 
Only those live targets which reside inside a 
LAOI shall be considered “detected” by the 
RPS. ___ 


Only those virtual targets which reside 
outside the LAOIs (aka virtual area) and 
within the current radar beam dwell 
footprint shall be considered for possible 

“detection” by the RPS. _ 

For each radar beam dwell, the detected live | 
moving targets (3.2.2.1.3) and the detected 
virtual moving targets (3.2.2.2) shall be 
merged into a single dwell report 
representing a mix of live and virtual targets 
within the same beam, but not overlapping 
in physical space. 


After the MTI control function (3.2.2.1) 
filters the virtual targets based on beam 
dwell and LAOI geometry, this simulation 
shall create a subset of these virtual targets 
which exhibit similar characteristics as live 
Joint STARS targets would under the same 
scan conditions. 






































Item 


30 I 3.2.2.2.2.1 


31 I 3.2.2.2.2.2 


32 I 3.2.2.2.2.3 


33 I 3.2.2.2.3 


34 1 3.2.2.2.3.3 












40 3.2.2.2. 


Paragraph Title 

Method 

Weather 

Inspection 

Refraction 

Inspection 

Terrain 

Test 

Virtual Target Statistics 

Inspection 

Location Accuracy 

Test 

Probability of Detection (Pd) 

Analysis 

Probability of Detection (Pd) 

Analysis 

1 

Probability of Detection (Pd) 

Test 

1 

i 

( 

( 

Probability of False Alarm (PFA) 

Test 1 

< 

I 

( 

k 

Target Classification (TC) 

Analysis ^ 

s 

c 

2 

1 

Modeling 

Analysis > 

c 

\ 

( 

5 


Requirement 


Weather conditions shall be assumed to be 
one of three categories; (1) clear; (2) cloud; 
(3) rain; as defined in the Joint STARS 
System Specification, as selected by the 
JAPS operator (3.2.1.2). 


The method employed by Joint STARS to 
determine the range refraction correction 
shall be used by the RPS to enhance 
symmetry between live an virtual targets. 


The RPS shall identify those virtual targets 
obscured by terrain based on the 
hypsographic database, and the current 
platform position along the radar beam’s 
line of sight. 


MTI statistics shall be applied stochastically 
to the virtual targets using a uniformly 
distributed random number sequence in 
order to effectively simulate virtual targets 
as Joint STARS targets. 


Once the down range and cross range error 
has been established, these values shall be 
applied to the position vector (Pt) of the 
target. 


Radar operating curves (3.2.2.2.4) shall be 


)er section (3.2.2.2.4). 
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Item 

Paragraph 

Paragraph Title 

Method 

Requirement 

41 

3.2.3 

SAR Imagery Simulation 

Demonstration 

The SAR Imagery simulation shall receive 
as input from the RPS Control function 
(3.2.1) the SAR beam dwell data and the 
stationary virtual targets received over the 
DIS network. 

42 

3.2.3 

SAR Imagery Simulation 

Test 

Requests for SAR or FTI service shall be 
considered a virtual SAR / FTI request if 
the central reference point (CRP) defining 
the SAR / FIT AOI falls within the virtual 
area. 

43 


Stand Alone Mode 

Demonstration 

The RPS shall be capable of executing in a 
simulation only mode, referred to as the 
Stand Alone mode, such that the RPS 
functions in the same manner as during 
flight mode, but without live data inputs. 

44 

3.2.4.1 

Radar Control Simulation 

Demonstration 

The radar AUX data containing sensor 
commands used by the radar during each 

CPI shall be simulated based upon the 
commands given in the Primary Mode 
Control (PMC) message sent by the RDP 
for each radar beam dwell. 

45 

3.2.4.2 

PSP Simulation 

Demonstration 

The PSP setup / acknowledge, node 1, and 
node 2 communication paths with the RDP 
on the PSP LAN shall be modeled based on 
the RDP inputs. 

46 

3.2.4.3 

Navigation Simulation 

Demonstration 

The navigation data normally produced by 
the Joint STARS FMP CPCI Relative 
Navigation function shall be simulated by 
the RPS. 
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ABSTRACT 

The End-To-End Test (ETE) is being conducted under the auspices of the Department of Defense 
Joint Advanced Distributed Simulation (JADS) Joint Test and Evaluation (JT&E). The purpose 
of the ETE is to investigate the utility of using advanced distributed simulation (ADS) to 
augment both developmental and operational testing of the Joint STARS surveillance system. 
The basic concept behind the ETE is to augment the Joint STARS environment with a virtual 
environment created by thousands of simulated entities, or targets. This virtual environment is 
imaged by simulations of the radar systems contained within the Joint STARS E-8C aircraft and 
mixed with real radar returns to provide a robust operational environment for testing of the 
system. 

The ETE Joint STARS simulation is called the Virtual Surveillance Target Attack Radar System 
(VSTARS). Simulated entities are transmitted to VSTARS through the use of Entity State 
Protocol Data Units (ESPDU). The simulation, or simulations, representing these entities 
transmit ESPDUs representing the status of each entity. This status is used to update data bases 
that are used to generate Joint STARS virtual radar images. Two modifications have been made 
to the ESPDU for use in the ETE. The first of these is a modification of the time field and is not 
mandatory, but is recommended. It records the time the ESPDU was created since the start of the 
simulation scenario. The second change to the ESPDU is performed internal to the Joint STARS 
simulation and is much more drastic. VSTARS must be capable of functioning anywhere 
needed, to include on board an aircraft during the conduct of a mission. This requires that the 
DIS network interface unit (NIU) for VSTARS exist in two parts, a ground NIU (GNIU) and an 
aircraft NIU (ANIU). The GNIU remains at a fixed location and receives ESPDUs from the DIS 
network. It then strips and modifies the ESPDU down to 192 bits of essential information and 
sends it to the ANIU. The ANIU performs the dead reckoning function and updates the data 
bases used to generate the virtual radar images. The ANIU resides in the same computer hosting 
VSTARS and may be found in a variety of locations such as a laboratory, on board the aircraft, or 
at a training site. This paper describes the modifications to the ESPDU and some of the reasons 
for the modifications. This procedure can be tailored for any sensor system that is not easily 
connected to a DIS network. 
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INTRODUCTION 


The End-to-End Test (ETE) of the Joint Advanced Distributed Simulation (JADS) Joint Test 
Force (JTF) will evaluate the utility of using advanced distributed simulation (ADS) to 
complement the developmental and operational test and evaluation of a Command, Control, 
Communications, Computers, and Intelligence (C4I) system. The Joint STARS combination of 
E-8C aircraft and Ground Station was chosen as a representative C4I system on which to 
introduce ADS as a methodology in both DT&E and OT&E settings. 

Joint STARS provides commanders access to near real-time radar imagery data in support of 
targeting decisions. The E-8C aircraft radar looks deep into hostile areas to detect, locate, 
classify, and track thousands of potential targets. This radar operates in two basic radar modes: 
moving target indicator (MTI) and synthetic aperture radar (SAR). MTI is capable of displaying 
the position of moving ground vehicles. SAR can provide images of both moving and 
nonmoving targets and of terrain and cultural features. 

Previous C4I system testing has exhibited shortfalls in providing adequate numbers of forces, 
friendly or enemy, to realistically portray an expected operational environment. ADS can 
generate a robust test environment by providing a more representative number of threats, plus the 
complementary suite of other C4I and the weapons systems that interact with a C4I system. 
Through a seamless mixing of live and virtual targets, the ETE will add thousands of additional 
entities to the few hundred available in peacetime battlefield exercises, and will better replicate a 
developed theater. 

The ETE is a four-phase test. Phases 1 and 2 occur in a laboratory environment, suitable for 
exploring DT&E and early OT&E applications. Phase 3 checks compatibility of the ADS 
environment with the actual Joint STARS equipment. Phase 4 is an ADS-enhanced live open-air 
test linking a flying E-8C aircraft to actual ground station receivers, intelligence systems, fire 
control, and virtual shooters. A schematic of Phase 4 is shown below. 
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Figure 1. EXE Architecture 


RF LIMITATIONS 

In a typical DIS network, all simulation components are linked over local or wide-area ground- 
based networks. The ETE will link such ground networks, but also must include a flying aircraft 
receiving update information from a DIS network. This presents special challenges due to 
constraints on available radio frequency (RF) bandwidth between a ground transmitter and a 
receiver on board the aircraft. Current RF bandwidth available for the ETE is limited to around 
19.2 kbps. 

The current ETE network interfaces support a maximum of 100 ESPDUs per second. The DIS 
version 2.0.4 ESPDU contains 1152 bits of information (minimum), requiring a transmission rate 
of (1152)(100) = 115 kbps, much greater than the available bandwidth. Additionally, the E-8C 
aircraft provides an ESPDU denoting its existence and flight information on a 1 Hz update. This 
bandwidth discrepancy drove development of the modified ESPDU and network interface units 
used in the ETE. 

ETE ARCHITECTURE 

The VSTARS architecture receives ESPDUs from a DIS network through a ground network 
interface unit (GNIU), and transmits a modified PDU via an RF datalink to the corresponding air 
network interface unit (ANIU) aboard the flying aircraft. 
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Figure 2: VSTARS Network Interface Units 


NETWORK INTERFACE UNITS 

The Ground Network Interface Unit first determines if arriving PDUs are Entity State PDUs. It 
then filters out those ESPDUs that are not within the E-8C simulation’s area of interest. The 
remaining ESPDUs are stripped to a data packet containing the minimum information required to 
drive the MTI and SAR simulations in VSTARS. (This process is described later in this paper) 
The GNIU converts location coordinates from DIS Earth-Centered-Earth-Fixed to the 
Topocentnc Coordinate System used on-board the E-8C and in the RPSI. This conversion is 
done on the ground to save processing cycles onboard the aircraft. The GNIU then constructs an 
RF link message and transmits a stripped and modified data packet containing ground target 
information to the receiving ANIU. 

The Air Network Interface Unit receives the incoming data packet and places the information in 
its target database. The ANIU performs dead reckoning on these targets, and updates the 
database based on its dead reckoning estimations and incoming target information. Dead 
reckoning is done on-board the aircraft to save RF transmission bandwidth from the GNIU. On 
request from the RPSI, the ANIU searches its database for those targets located in the appropriate 
ground location and provides such data to the RPSI SAR or MTI simulation. 


Conversely, VSTARS provides to the ANIU data regarding the existence and location of the E- 
8C aircraft. The ANIU then composes and transmits a location data packet back to the GNIU 
denoting this information. The GNIU reforms the E-8C data into a DIS 2.0.4 ESPDU and 
broadcasts it to the DIS network. 

ESPDU UPDATE MODIFICATIONS 

DIS simulations normally send out ESPDUs on both a dead-reckoning update and a heartbeat 
basis. Dead-reckoning updates are sent whenever an entity location maintained in the 
simulation’s internal location database exceeds by a given error parameter the locations 
maintained in some external DIS simulation database. Heartbeat ESPDUs are broadcast on a 
periodic basis (once every five seconds is recommended by the DIS standard) to permit 
simulations just entering the DIS network to initialize their databases, and also for those visual 
engines that require periodic updates. 
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The EXE simulation driver broadcasts dead-reckoning ESPDUs using the locational error 
parameters of the E-8C radar (i.e., radar CEP). This parameter can be decreased in the 
simulation software as necessary to account for latency in the ETE network. For example, 
assume the E-8C locational parameter error is 50 meters. A vehicle traveling at 5 meters / 
second can exceed the locational error in 5 seconds, necessitating an ESPDU update within 5 
seconds. However, if network latency is 1 second, the dead-reckoning update must be shortened 
by at least 1 second (by adjustment of locational error parameter) for locational accuracy to 
remain within the aircraft radar CEP. Reducing the E-8C locational error parameter setting to 30 
meters would require an ESPDU update in 3 seconds. On top of the 1 second latency, the 
updated ESPDU would arrive at a distant simulation in 4 seconds, which in effect is less than the 
radar CEP. 

Between dead-reckoning updates, the ETE simulation driver broadcasts heartbeat ESPDU 
updates. Since the ETE network architecture and simulation participants are fixed prior to 
exercise initiation, no new players will join once the exercise begins; therefore, the newly 
entering simulation heartbeat requirement is eliminated. Also, none of the ETE visual engines 
require periodic updates. Were it not for the small chance of a non-mover being accidentally lost 
from the VSTARS database, this heartbeat could be eliminated. For VSTARS, the heartbeat is 
set initially and arbitrarily at a 10-minute update interval. 

ETE ESPDUs arriving at VSTARS are maintained in a target database. Targets that are moving, 
or those stopping or starting, are updated as described above. Stationary targets are initialized in 
the database at exercise initiation. Once entered in the ANIU target database, targets are not 
routinely removed. Those targets that become battle-damaged or destroyed remain as burning 
hulks to be imaged by the E-8C SAR radar. 

ESPDU DATA MODIFICATIONS 

The VSTARS simulation driver need not provide the extensive target data available from the 
standard DIS ESPDU — information such as color, national origin, model, and so on is simply 
not visible to the E-8C radar sensor. This allows the ETE to strip such information from the 
ESPDU, and results in a smaller data packet that must be transmitted to the flying aircraft. 
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Field Size 

ETE Modified ESPDU 

PDU Header 

Time Stamp 

32 

Entity ID 

Entity 

16 

Entity Type 

Category 

8 

Subcategory 

8 

Specific 

8 

Extra 

8 

Entity Linear 
Velocity 

X-Component 

16 

Y-Component 

16 

Z-Component 

16 

Entity 

Location 

X-Component 

16 

Y-Component 

16 

Z-Component 

16 

Entity Orientation 

Psi 

16 

PDU Size 

192 bits 


Chart 1. ETE Modified ESPDU 



Field Size 
E-8C ESPDU 

Header 

Time stamp 

32 

E-8C Location 

X-Component 

32 

Y-Component 

32 

Z-Component 

32 

E-8C Velocity 

X-Component 

32 

Y-Component 

32 

Z-Component 

32 

TBD 

reserved 

32 

Total PDU Size 


256 


Chart 2: ETE E-8C ESPDU composition 


• The VSTARS time stamp records the 
ESPDU creation time for up to 8 
exercise hours, compared with the DIS 
protocol of restarting every hour. This is 
required by a normal 8 hour Joint 
STARS mission length. 

• Entity Type contains the minimum 
information required for an overhead 
radar sensor as described above. 

• Location data has been converted from 

Earth-Centered-Earth-Fixed to 

Topocentric Coordinate System and 
reduced to 16-bit accuracy, sufficient to 
remain within the error requirements of 
the E-8C radar. 

• Likewise, velocity data has been reduced 
to 16-bit accuracy. 

• Orientation is restricted to that visible to 
the E-8C radar in the radar slant plane. 

Total Modified ESPDU size is 192 bits, 

compared with 1152 + 128n bits in the DIS 

2.0.4 ESPDU. 


The E-8C aircraft transmits a 1 Hz state 
message from the ANIU to the GNIU 
denoting its existence, location, and 
velocity. The GNIU translates this into an 
E-8C ESPDU and broadcasts over the DIS 
network. This information permits the 
aircraft to be visible to other players in the 
DIS environment. 
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This results in the following transmission bandwidth requirements. 



entities / sec 

# entities 

#bits 

kbps 

Uplink Messages, 

GNIU to ANIU 

Max sustained rate 

100 


19,200 

19.2 


10 min heartbeat rate 

33 

20,000 

6,400 

6.4 

Downlink Messages, 
ANIU to GNIU 

Joint STARS state 
message @ Ihz 

1 

1 

256 

0.26 

Total RF link bandwidth requirements 


25.86 


Chart 3: Transmission Bandwidth 


Available ETE RF bandwidth to the ETE is 19.2 kbps. Using a nominal compression ratio of 
1.4:1, the required bandwidth is reduced to 14 kbps, which fits within capacity. 

CONCLUSIONS 

For an overhead stand-off system such as MTI or SAR radar, the DIS ESPDU can be drastically 
reduced in size and still provide the resolution and fidelity necessary to provide accurate sensor 
information for training exercises or developmental and operational testing and evaluation. Such 
a procedure can be applied to any sensor that cannot ‘see’ all the detailed information available in 
the DIS ESPDU. The combination of ESPDU stripping and update rate modifications allows a 
flying aircraft to participate in a realistic DIS exercise. These procedures can be used to bring 
together various real combat equipment linked over radio nets into a DIS simulation without the 
restrictions posed by limited RF bandwidths. 
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1. Introduction 


This document reports on the results of work conducted by Northrop Grumman to demonstrate 
the utility of existing Advanced Distributed Simulation (ADS) for use during Multi Service 
Operational Test and Evaluation (MOT&E). This project was sponsored by the Joint Advanced 
Distributed Simulation (IADS) Joint Test Force (JTF). This white paper documents the Scientific 
and Technical accomplishments through Phase lb of the program. This phase provided for a 
laboratory system development, demonstration, and preliminary performance assessment of a 
Radar Processor Simulation and Integrator (RPSI), for the purpose of simulating the Joint 
Surveillance Target and Attack Radar System (JSTARS) Radar products, with connections via 
the Distributed Interactive Simulation (DIS) network to the JADS End to End (ETE) simulated 
environment (SE). 

ADS is defined as "any application or architecture which employs the characteristics of 
distribution and networking in a way which permits a number of nodes, entities, or devices (at 
least two) to interact with each other for some common or shared purpose related to Test and 
Evaluation (T&E), thus allowing the creation of realistic, complex, virtual worlds for the 
simulation of highly interactive activities.” The three possible types of players (also known in 
the DIS community as participants or entities) are listed below: 

• Live: real systems, real people, and real environments, operational platforms and test and 
evaluation systems. 

• Virtual: simulators HIL/HWIL (Human in the Loop/ Hardware in the Loop) 

• Constructive: models, digital simulations, computer generated forces, systems and 
environments and war games. 

The term ADS has been developed to include network implementations which do not completely 
conform to the IEEE 1278 standards, but otherwise adhere to the basic tenets of DIS as described 
above. The term ADS includes DIS as a subset and is intended to support a mixture of virtual, 
live, and constructive entities. Northrop Grumman currently is contracted by the Joint Advanced 
Distributed Simulation Joint Test Force (JADS JTF) to develop a Joint STARS RPSI which 
interfaces to the DIS network. The DIS network is a media for participation in ADS activities. 

2. Summary of the Project 

The objective of this effort was to develop a system to enhance the existing JADS. JADS is 
being developed to prove the ADS concept by means of an ETE test scenario, whereby a 
battlefield environment is simulated including multiple moving and non moving targets, toget 
detection, assignment, reporting, and target engagement. The Joint STARS E-8C platform is to 
be a major participant and will utilize the Joint STARS Radar and the RPSI to support the ETE 
Test that will be conducted by the JADS JTF. The integrated E-8C Radar and simulation will 


D- 7 



provide simulated Radar reports integrated with live Radar reports when operating within the 
JADS JTF ETE Test environment. 

Northrop Grumman was contracted to develop and implement a laboratory version of the RPSI 
and to provide the connections via the DIS to the JADS ETE simulated environment. Phase la 
consisted of an architecture and design study to determine the feasibility of the product. (See 
References 2, 3 and 4). The scope of the Phase lb effort, which was based on that work included 
the design and development of VSTARS software compatible with JADS and the DIS network 
and standards. This software was integrated in commercial hardware with ancillary Radar control 
software tasks, i.e., those which normally are provided by the actual E-8C Prime Mission 
Equipment (PME). Some of the Joint STARS software was modified for use with the RPSI 
VSTARS is the laboratory version of the RPSI, and is a simulation environment representing the 
generation and dissemination of Radar products by the Radar Subsystem of the E-8C aircraft. 

Northrop Gramman has developed VSTARS consisting of a Distributed Interactive Simulation 
Interface Unit (DISNIU), a Radar Processor Simulator and Integrator (RPSI), and a Datalink 
Databus Interface Unit, to conclude Phase lb. The RPSI is stimulated by virtual target data which 
are received in the form of Entity State Protocol Data Units (ES PDU) from the DIS network. 
These PDUs which are generated by a scenario generator, are data which describe the position 
motion, orientotion and identity of the virtual targets. The RPSI receives Radar Service Requests 
(RSR) from either an operator work station (OWS) or a Ground Station Module replica (GSMR) 
and provides Radar Target Reports (MTI and SAR) to the OWS and to the GSMR. In VSTARS, 
RPSI communication with the GSMR is provided by software tasks and a telephone link which 
simulate the Surveillance Control Data Link (SCDL) of the E-8C. The SAR simulation was 
developed by Lockheed Martin and was integrated into the RPSI by Northrop Grumman. 

In addition, a preliminary performance assessment of VSTARS was successfully conducted, to 
ascertain that VSTARS satisfied the requirements and was ready for the planned follow-on 
phases of the JADS ETE program. This included characterization of the DIS interface by 
measuring the rate at which the entity state PDUs can be received. 


The planned follow on JADS’ phases are intended to verify and validate the results of this work, 
to mi^ate the RPSI to the Primary Mission Equipment (PME) of the E-8C aircraft, to conduct 
operational tests of the RPSI in a flying E-8C aircraft, and to support JADS ETE Team tests. 


D 


8 



3. Task Description 


The scope of this task included the design, development and test of software compatible with the 
existing JADS SE for the purpose of simulating the Joint STARS Radar effects on virtual 
targets. 

The tasks which have been conducted during Phase lb, were to develop a DIS Network Interface 
Unit (DISNIU), a RPSI and a Databus Datalink Interface Unit to satisfy the following 
requirements: 

• Develop a DISNIU to receive, process and transmit DIS virtual target ES PDUs to the RPSI, 
and to transmit aircraft ES PDUs to the DIS network. Develop the DISNIU such that it can 
later be implemented in the E-8C PME. 

• Develop a Joint STARS simulation consisting of a RPSI, which simulates the E-8C Joint 
STARS Radar Subsystem products and provides reports to OWS, and to remote ground 
stations, the latter via a specialized connection to a WAN. The RPSI architecture is in 
accordance with Architectural candidate 2, as described in reference 2, and satisfies the 
following requirements: 

• Provides for integration of simulated and live radar data when operating within the JADS 
Joint Test Force ETE environment. 

• Simulates the generation of MTI, SAR and Fixed Target Indicator (FTI) reports. 

• Operates in three modes: mixed, virtual and real. 

• Implements dead reckoning algorithms to minimize DIS network virtual target update 
requirements 

• Provides real or simulated aircraft inertial data information to the MTI and SAR 
simulations. 

• Is implemented within a commercial representation (ALPHA 600 Workstations) of the 
Joint STARS E-8C PME, in the Northrop Grumman ITF. 

• Develop a Databus Datalink Interface Unit to enable the transmission SCDL traffic (MTI and 
SAR reports) to an Army GSM or CGS or replica of such; and to enable reception of Radar 
service requests from the ground station. 
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4. Technical Approach 

The following paragraphs describe the work that was performed, the architecture selected, and 
the design of the RPSL It also describes the associated interfaces between the JADS JTF 
facilities and the laboratory version of the RPSI, VSTARS. The RPSI software tasks are 
integrated with actual Radar subsystem software. Since the approach was to develop the RPSI to 
execute initially in the NG laboratory in ALPHA 600 work stations, and then in later phases to 
execute in the E-8C PME, existing Joint STARS subsystem software modules were integrated 
with the RPSI in the ALPHA 600 computers. These modules were augmented with additional 
software tasks, which were designed to intercept normal post processing outputs in order to insert 
simulated target information, and to provide the interfaces with the DIS network and the SCDL 
emulation. This provides for MTI and FTI reporting of the virtual targets and virtual SAR. 
During the planned follow on phases, only the newly developed and modified software will need 
to be imgrated to the JSTARS PME, since the other Radar functions will be provided by existing, 
unmodified portions of the Radar subsystem. 

4.1 RPSI Architecture and Design 

The RPSI was developed to be in accordance with Architectural candidate 2, as described in 
Reference 2. Whereas the RPSI currently is implemented in commercial hardware in the 
laboratory, it was designed to enable the functional partitioning shown in Figure 4.1 when it is 
migrated to the E-8C PME. This figure shows the planned partitioning of the RPSI software to 
execute primarily in the “spare” general purpose computer (GPC-3), and in one of the Advanced 
Technology Workstations (ATWS). The following paragraphs describe VSTARS, the laboratory 
version of the Radar simulation. 
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Figure 4.1 RPSI Functions to be Installed in JSTARS PME 


4.2 VSTARS/RPSI Relationship to JSTARS 

VSTARS was developed from a combination of existing Joint STARS Radar software and new 
software, and executes in two DEC ALPHA 600 workstations. It should be emphasized that the 
RPSI does not operate on its own but is integrated with actual Radar subsystem software. 

VSTARS operates as follows: 

Virtual target ES PDUs are received via a LAN and a T1 communication service, from the 
remote scenario generator, JANUS, via the DIS network. VSTARS DISNIU software receives 
and processes the PDUs, placing the virtual target data in global memory. The RPSI software 
accesses this data, simulates MTI and SAR processing affects and generates Radar Reports. 
These reports are provided via a LAN, for display at the OWS, or for transmission via a SCDL 
emulation to a remote GSMR, via a WAN (T1 communications service). The RPSI also receives 
Radar Service Requests from the GSMR via this WAN, and these are executed by VSTARS. 

The combination of existing or modified Joint STARS Radar software and the newly developed 
RPSI software modules, which were migrated to the ALPHA 600 computers to perform these 
tasks are depicted in the following figures as unshaded and shaded blocks respectively. The 
“unshaded” functions provide for the auxiliary and parameter messages and controls, and 
reporting processes which normally are provided by the actual Radar Subsystem. Some of the 
“shaded” functions provide for the DISNIU functions, which receive and process the ES PDUs 
(bit stripping, coordinate conversion and dead reckoning which are described below). Other 
shaded functions provide for the SCDL emulation. Additional shaded functions provide the 
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simulation of MTI and SAR/FTI processing and product generation, and provide the interfaces 
between the RPSI and the Radar software tasks. Although the SATCOM Subsystem block is 
shown as shaded, the SATCOM processor software will be modified in the planned follow-on 
phases, to provide the RF link between the RPSI and the DIS network. 

The result is a simulation of the Joint STARS Radar products “in a box” (the ALPHA 600 
commercial computers), providing all of the JSTARS databases, post processing, operator 
displays and controls, and Operation and Control (O & C) Subsystem functions (e.g., target 
tracking and reporting) which are necessary for a realistic simulation of the Joint STARS Radar 
products generation and display and O & C Subsystem functions and interfaces. 

Figure 4.2 provides a block diagram of the MTI processing mode and is an example of the 
relationship between the major Radar functions of the RPSI and of the Joint STARS RADAR 
software which comprise VSTARS. Figure 4.3 is the corresponding block diagram for the SAR 
processing mode of the RPSI. The operation of the RPSI Interfaces and the MTI and SAR 
simulation software tasks are described below in Paragraphs 4.2.3 and 4.2.4. But, first the RPSI 
laboratory hardware configuration and functional partitioning are described. 



Figure 4.2 MTI Mode Shows Relationship & Dependency of the RPSI to the JSTARS 

RADAR 
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Figure 4.3 SAR Mode Block Diagram Shows Relationship & Dependency of RPSI TO 

JSTARS RADAR 

4.2.1 Laboratory Hardware Configuration and Functional Partitioning 

Figure 4.4 shows the laboratory configuration of the RPSI, known as VSTARS. VSTARS 
provides the software functions of the Joint STARS System Management and Control (SM&C) 
computer, the Radar Data Processor (RDP, known as GPCl), the Central Data Computer (CDP, 
known as GPC2) and the Advanced Technology Workstation (ATWS), by utilizing the actual 
Radar System software modules. As noted above, some of these were modified and additional 
software modules were developed for VSTARS. 

At present all of VSTARS is configured to run on dual ALPHA 600 workstations with software 
functions partitioned as shown in Figure 4.4, or on a single ALPHA 600. SAR generation occurs 
more rapidly when two ALPHA 600s are utilized. Each ALPHA 600 is equipped with a single 
333-Mhz CPU. One is equipped with 512 MBytes of RAM, the other with 1 GByte of RAM for 
SAR processing. The operating system is DEC Open VMS Version 7.0. The VSTARS software 
baseline is a variant of Joint STARS software Build 108B. 
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One of the workstations (JADSOl) interfaces via an Ethernet LAN with an SGI workstation 
which is used for logging or playback of the DIS PDUs. The SGI and the ALPHA 600 
workstations connect via the LAN to a T-1 communication service network, which provides the 
interface to the DIS network. The interface which emulates the SCDL to the GSMR also is via a 
T1 communications service. 

Both the DEC ALPHA 600 operator workstation keyboards and displays in the Northrop 
Grumman “JADS Laboratory”, and the E-8C PME operator work stations (OWS) in the 
Northrop Grumman OCTL laboratory have been utilized with the RPSI executing in the ALPHA 
600s. Since the latter OWS are the same as those utilized in the E-8C aircraft, they are utilized 
for realistic demonstrations of VSTARS and are recommended for realism when operator 
performance tests and assessment of VSTARS are to be conducted. 



Figure 4.4 VSTARS, the Laboratory Configuration of the RPSI 
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4.2.2 DIS Interface Design and Operation 


The DIS Interface provides for the receipt of ES PDUs from any DIS compliant PDU generator, 
(see Reference 6). For this project, PDUs were generated by JANUS and delivered via the T1 
service and a Northrop Grumman Ethernet LAN directly to the DISNIU software tasks, or 
replayed from the SGI logger, which also records and can replay the PDUs that are received from 
JANUS. In order to provide for the eventual migration of the RPSI to an E-8C aircraft, the 
DISNIU software was designed with two parts: a Ground DISNIU (GNDNIU) and an Air 
DISNIU (AIRNIU). In VSTARS, the laboratory version of the JSTARS Radar emulation, both 
DISNIUs execute in an ALPHA 600. In the planned aircraft version, the AIRNIU will be 
installed in the aircraft PME. The GNDNIU will remain in the laboratory ALPHA 600 which will 
be interfaced with a ground site SATCOM system to provide an RF link to the aircraft (see 
section 4.2.7), and thence to the AIRNIU. 

The GNDNIU software module (see JADSOl in Figure 4.4) interfaces with the Northrop 
Grurrmian Ethernet LAN which in turn interfaces with the DIS network via the T1 
communication service. Although there are provisions for more than 1152 data bits in the 
standard DIS compliant PDU, this data was reduced to 192 bits in order to minimize the 
bandwidth requirements for passage of the target data to the aircraft. To achieve this 
compression, the PDUs received by the GNDNIU are stripped of the unnecessary data. The 
position and velocity data of the ESPDU are coordinate converted from an earth centered 
(geodetic) coordinate system to the Topocentric Coordinate System (TCS), which is employed by 
the JSTARS. The conversion algorithm utilizes the current Joint STARS mission center and 
supports the 512 by 512 km JSTARS mission area. The virtual target position is quantized to 16 
meters and velocity is quantized to 0.0061 meters/second. The resultant 192 virtual target data 
bits (see Table 4.1) are forwarded to the AIRNIU. 

This virtual target data is received from the GNDNIU by the AIRNIU and stored in global 
memory. Periodically, (currently once per second) the target position (of moving targets) is 
updated by dead reckoning. This data is available for further processing in the MTI or SAR 
processing mode, as described in the following sections. 

The AIRNIU also has been designed to periodically (currently once per second) acquire and send 
an aircraft PDU to the GNDNIU, which in turn will deliver the aircraft PDU to the DIS network. 
Table 4.2 shows the PDU fields for this JSTARS downlink PDU. Although the RPSI simulates 
the generation and sending of aircraft PDUs, the software is designed so that the default mode for 
this function is “OFF’, in order to eliminate any interference during the receipt of ES PDUs from 
the DIS network during laboratory tests. 
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Table 4.1 Uplink Entity State PDU for JADS RPSI 


FIELD DATA 

FORMAT 

BITS IN FIELD 

INFORMATION 

Time Stamp 

Unsigned Integer 

32 


Local Target ED 

Unsigned Short 

16 

Local Target ID No. 

TCS X Cell 

Unsigned Short 

16 

4K cell and 16m cell 
in Y axis 

TCS Y Cell 

Unsigned short 

16 

4K cell and 16 m 
cell in X axis 

TCS Z Cell 

Unsigned Short 

16 

(16383)m lsb=0.5m 

Velocity X 

Short 

16 

(200)m/s 

lsb=6.1035mm/sec 

Velocity Y 

Short 

16 

(200)m/s 

lsb=6.1035mm/sec 

Velocity Z 

Short 

16 

(200)m/s 

lsb=6.1035mm/sec 

Entity Category 

char 

8 

enumeration 

Entity Sub Category 

char 

8 

enumeration 

Entity Specific 

char 

8 

enumeration 

Appearance 

char 

8 

8 bit extraction from 
32 bits 

Orientation Angle 

short 

16 

(180)deg. extraction 
from 32 bits 

TOTAL BITS 


192 



Table 4.2 Downlink Entity State PDU for JADS RPSI 


FIELD DATA 

FORMAT 

BITS IN FIELD 

Time Stamp 


32 

TCS Location X 

Float 

32 

TCS Location Y 

Float 

32 

TCS Location Z 

Float 

32 

TCS Velocity X 

Float 

32 

TCS Velocity Y 

Float 

32 

TCS Velocity Z 

Float 

32 

TBD 

Integer 

32 

TOTAL BITS 


256 
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4.2.3 MTI Processing Simulation 


The MTI simulation, which was designed for the laboratory version of the RPSI, is illustrated in 
Figure 4.5 which shows the major software tasks and message flow. 
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Figure 4.5 RPSI MTI Processing Simulation (Laboratory Mode) 

RCUSIM and PSPSIM are software tasks which were developed for VSTARS, to be used in the 
laboratory version of the RPSI. These software modules provide for those inputs which normally 
are provided by the actual Radar Control Unit (RCU), and the Programmable Signal Processors 
(PSP) of the Radar system. These operate in conjunction with new RPSI software tasks. 

MTISIM and the DISNIU software tasks and the modified PK2MCP, PK4RPT and PK5SRM 
software will form part of the RPSI software which will be migrated to the E-8C PME during 
follow on phases. PSPSIM and RCUSIM will not be required in the aircraft, since the functions 
which are provided by these software tasks in the laboratory will be provided in the aircraft by 
the Programmable Signal Processors (PSP) and the Radar Control Unit (RCU) of the JSTARS 
Radar subsystem. 
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The new RPSI software task, MTISIM, receives the virtual target data from global memory, and 
processes the virtual targets that fall within the MTI dwell. This task “detects” virtual targets 
based on target probability of detection (Pd), velocity, and terrain and generates a combined MTI 
report containing virtual and real targets (in mixed mode). MTISIM performs the following 
major operations: 

• Processes the MTI parameters message and identifies the 4km by 4 km grids 
encompassed within an MTI dwell. 

• Builds the MTI dwell data structure. (RSR ID, Number of Live AOI, PRIs, MTI 
resolution, etc.,) 

• Determines if any ‘Live” MTI targets must be loaded into the combined JADS MTI 
Target Report 

• Determines if any Virtual MTI targets must be loaded into the combined JADS MTI 
Target Report 

• Applies Probability of Detection (Pj) and Target Location Circular Error Probability 
(CEP) statistics (see Reference 4 and Section 0), and Terrain Screening tests for each of 
the Virtual targets located within those 4x4 km. grids which are within the Radar 
footprint. 

• Issues the combined JADS MTI Target Report to the Operator Work Stations and to the 
SCDL interface. 


The two most observable performance characteristics of target reports from the Radar are Pd and 
tarpt location accuracy. The high fidelity Pd computation accounts for the various target to noise 
ratio losses and processing gains characterizing the Radar, the environmental conditions and the 
geometric relationship of the target to the Radar scan. The Pd calculation was fine tuned based on 
actual JSTARS System Level Performance Verification (SLPV) flight test data, (see Section 5) 
An analysis of controlled SLPV flight test data provided the best insight into the actual errors 
that were modeled for the JADS simulation. 

An example of the comparison between SLPV flight test data and the JADS simulation is shown 
below in Figure 4.6 for twelve distinct SLPV Test Points. The chart shows that the JADS 
estimate of Pd was slightly more optimistic than the flight data (on average about 3-4%). This can 
easily be attributed to errors in the assumptions of target size and environmental conditions. 
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Figure 4.6 Comparison of Pj for JADS Simulation and SLPV Flight Test Data 

MTI target location error statistics derived from the 1 sigma errors in range, cone angle, vertical 
separation and coordinates also were applied. These were derived from a two dimensional 
theoretical model and from SLPV flight data taken under controlled conditions. The down range, 
cross range and Circular Error Probability (CEP) statistics were utilized in the JADS CEP 
algorithms and applied to the JADS virtual targets based on their true range and angle to the 
aircraft. 


Figure 4.7 below provides an example illustrating the close similarity in the frequency 
distributions of cross range error for the Live data that was derived from SLPV flight data, and 
the corresponding cross range error from the JADS simulation. 
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Figure 4.7 Cross range error distributions for Flight Test Data and JADS Simulation Data 

Radial Velocity quality and error statistics also were derived from data collected under controlled 
conditions during SLPV flight tests. A more detailed description of all these analyses and results 
is presented in Section 5 of this report. 

The MTI simulation software tasks operate as follows in the laboratory version: The JSTARS 
software task, PK8RSC (radar sensor control), commanded by receipt of a Radar Service Request 
(RSR), sends Primary Mode Control (PMC) messages to the VSTARS task, RCUSIM, which 
generates and sends Radar Auxiliary Data messages to the JSTARS Radar Data Processor (RDP) 
MOCOMP task, PK2MCP. The VSTARS task, PSPSIM receives MTI parameters message from 
PK2MCP and generates and forwards an MTI node 1 report with random radar hits representing 
live (noise in the laboratory version) MTI data to the JSTARS RDO task, PK4MTI, which 
provides a Target Association report to PSPSIM. PSPSIM then provides a Live MTI “node 2 
report to the JSTARS task, PK4RPT, from which after coordinate conversion (range-angle to 
TCS) and formatting, the Live MTI Report is sent to the RPSI task, MTISIM. MTISIM also 
receives the MTI parameters message from PK2MCP. MTISIM processes the virtual target data 
and issues the combined Live and Virtual MTI Target Report to the Operator Work Station for 
display. 
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4.2.4 SAR Processing Simulation 


The SAR simulation which was designed for the laboratory version of the RPSI, is illustrated in 
Figure 4.8 which shows the major software tasks and message flow. When a SAR image is 
requested the RPSI generates realistic SAR images using a Lockheed Martin software product 
(Advanced Radar Imaging Emulation System, ARIES), which is integrated with the NG RPSI 
software. 



Figure 4.8 RPSI SAR Mode Processing Simulation (Laboratory Mode) 


When a SAR image is requested, for a particular SAR area of interest (AOI), the new RPSI 
software task, SARSM, receives the SAR Mid Array message from MTISIM, and if the SAR is 
in a “virtual area”, sends a SAR Simulation Parameters message to ARIES software modules (see 
Reference 5). The SAR Simulation Parameters message contains the SAR image request and the 
operational and navigational data including the AOI, sensor parameters (resolution, wavelength, 
dwell time, coverage width, range extent, antenna orientation), platform state data, and target 
information. ARIES generates the simulated SAR images from Digital Terrain Elevation and 
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Feature data bases for the AOI. ARJES takes this data and SAR parameters and develops a point 
map for locating terrain features including elevation and targets in the image. It then uses this 

map to perform a 3-D to 2-D projection that simulates what would be seen in the actual Radar 
Subsystem. 

A height parameter is used to generate obscuration, shadows and surface gain reflectivity, 
including edge reflectivity effects. Virtual targets, textures, and features are inserted into the 
image. Moving Targets are inserted last into the image. Image processing of this “raw” image 
blends edges, seams and boundaries. A simulated SAR Image Report that contains an image of 
the virtual area which was indicated in the SAR Simulations Parameters message, then is 
returned to SARSIM. SARSIM scan converts the SAR images from “range-doppler” coordinates 
to the X-Y pixel display format, and sends the images to the OWSs, and to the Operations and 
Control (OCO) CPCI when required for transmission via the SCDL. 

The SAR simulation software tasks operate as follows: When the JSTARS task, PK8RSC (radar 
sensor control) receives the RSR for a SAR image, it sends primary mode control messages to 
the VSTARS task, RCUSIM, which generates and sends Radar Auxiliary Data messages to the 
JSTARS RDO MOCOMP task, PK2MCP. PK2MCP sends SAR parameters and mid-array 
messages to PSPSIM and to MTISM. PSPSIM generates “Live” (fake data, derived from noise 
m the laboratory version) SAR data blocks. The RDO task PK4SAR, receives these multiple 
blocks and formats the “Live” SAR images. These images are then sent to the RPSI task, 

SARSIM. If the SAR has been requested for a “live” area this live SAR is forwarded to the 
OWS. Otherwise it is “dumped”. 


MTISIM loads dwell data, determines the virtual targets within the SAR Area of Interest (AOI) 
and determines whether the requested SAR is in a “Virtual” or a “Live” AOI. When the 
requested SAR is in a Virtual area MTISIM sends to the RPSI task, SARSIM, a new SAR 
parameters message containing the dwell data and mid array messages, and the virtual targets 
within the SAR AOI. When a SAR has been requested for a “virtual “ area, SARSIM sends the 
SAR Simulation Parameters message to ARIES, and ARIES generates the simulated SAR as 
described above. 

The ARIES and SARSIM software, and modified versions of PK2MCP, PK4SAR and PK5SRM 
will be migrated to the E-8C PME during JADS Phase 2. PK5SRM is the Radar Service Request 
Manager software task. 
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4.2.5 Navigation Simulation Processing 


In the E-8C platform, navigation sensor information is provided to the Radar subsystem by the 
navigation sensors. The navigation simulation process which was designed for ground and 
laboratory usage of the RPSI is illustrated in Figure 4.9. 
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Figure 4.9 Navigation Simulation Processing 

This process, NAVSM, simulates the various navigation sensors (GPS, INUs, IMG and CADCs) 
of the E-8C aircraft and thereby provides the needed navigation information to the RPSI. 
NAVSIM also generates and provides simulated aircraft position and velocity (as an aircraft 
PDU) to the DISNIU. Although NAVSIM will not be required for the aircraft version of the 
RPSI when the aircraft is flying (since the actual navigation sensors will be employed), it is 
expected that for ground tests of the RPSI in the PME, NAVSIM will be utilized. 

NAVSIM simulates and provides this navigation sensor data to the JSTARS software task, 
PUNRNG which normally executes in an SM & C computer of the E-8C PME. PUNRNG was 
modified for JADS and replicated in one of the ALPHA 600s (Figure 4.4). PUNRNG filters and 
merges the navigation sensors data and provides platform position, velocity and attitude Hata to 
the JSTARS task, PTRNAV for use in the RPSI MTI and SAR processing. PTRNAV normally 
executes in the SM&C and the RDP of the JSTARS PME, and was replicated in the AT .P H A 
600. Platform location data also are provided to the ATWS for display of the navigation data and 
a depiction of the orbiting aircraft. The platform position and velocity data also is made available 
for periodic (currently set at once per second) formatting and transmission of aircraft PDUs to the 
AIRNIU, for transmission to the GNDNIU and thence to the DIS network. (See Paragraph 4.2.2). 
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4.2.6 Data Link Interface Design (SCDL) 

In the laboratory version of the RPSI, a Databus Datalink Interface Unit was developed to enable 
the transmission of Surveillance and Control Data Link (SCDL) traffic (e.g., MTI and SAR 
reports) to an Army ground station such as a Ground Station Module (GSM) or Common Ground 
Station (CGS), or replica (GSMR) of such, and to enable reception by VSTARS of Radar service 
requests (RSR) from the ground station. 

fa the E-8C aircraft SCDL traffic is accommodated by a 1553B data bus between the Central 
Data Processor (CDP) and the SCDL Air Data Terminal (ADT), which interfaces with the 
ground Ration via an RF link. See Figure 4.1. The Datalink Communications Management 

controls and monitors the equipment in the datalink subsystem and provides for 
communications. DCM software normally executes in the Central Data Processor 
Operations and Control (O&C) Subsystem. DCM interfaces to the 
SCDL ADT via the 1553 digital data bus (DDB) interface task, PTBDDB, and this allows the 
ADT to communicate with the JSTARS Radar and O&C subsystems. 

For the laboratory version of the RPSI, the 1553B interface was bypassed and instead of the RF 
link, a LAN and T1 communications services were utilized as the communications media 
between VSTARS in the Northrop Grumman, Melbourne, FI. laboratory, and the Motorola GSM 
replica in Phoenix, Az. During JADS Phase 2 this communication will be from NG to the GSMR 

which will be located at Fort Hood. The simulation of the SCDL interface and communication is 
Illustrated in Figure 4.10. 

Existing JSTARS CPCI, DCM, and task, PTBDDB, which provide for the SCDL 
communications in the E-8C platform, were modified and replicated in one of the ALPHA 600s 

Two additional JADS software tasks (JDSRCV and JDSXMT) were designed to interface these 
functions and the T1 LAN. 

The JADS SCDL interface operates as follows: 

Modified SEM process, PTBDDB performs the following functions 

• Determines if JADS SCDL T1 LAN interface software is executing. 

• Stops all I/O which normally executes to the SCDL DDB 1553B card on the CDP when 
JDSXMT and JDSRCV are executing. 

• Reroutes SCDL Downlink messages (e.g. MTI and SAR reports) from the DCM CPCI to 
the JADS Transmit (JDSXMT) process. 

• Forwards all SCDL Uplink messages from the JADS SCDL Receive process (JDSRCV) 

to the DCM CPCI process PW5SUM. ^ 

• Simulates SCDL ADT functions to satisfy JSTARS software that the SCDL ADT is 
operational 
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SCDLTILAN 


Figure 4.10 SCDL Simulation (Laboratory Mode Only) 

The JADS SCDL software tasks perform the following functions: 

• JADS SCDL TRANSMIT PROCESS JDSXMT: 

• Reads Initialization parameters to determine which User Datagram Protocol (UDP) 
port is used for transmission, and the Motorola GSMR SCDL ADT Internet Protocol 
(IP) address. 

• Notifies PTBDDB of JDSXMT execution status via message at process initialization 
and shutdown. 

• Transmits SCDL DDB messages from the PW5SDM process to the Motorola GSMR 
SCDLTl LAN via UDP 

• Performs UDP socket cleanup and process shutdown 

• JADS SCDL RECEIVE PROCESS JDSRCV: 

• Reads Initialization parameters to determine which UDP port is used for reception, 
and the Motorola GSMR SCDL ADT IP address. 

• Notifies PTBDDB of JDSRCV execution status via message at process initialization 
and shutdown. 

PW5SUM receives via UDP all SCDL T1 LAN messages from the Motorola GSMR 
SCDL Ground ADT simulator via the SCDL T1 LAN. 
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• Forwards all SCDL T1 LAN messages to the PTBDDB process for processing bv the 
DCMCPCI. 

• Performs UDP socket cleanup and process shutdown. 


The JADS software tasks, JDSRCV and JDSXMT, will not be required in the aircraft. The 
functions which provide for SCDL data link in the aircraft already form a part of the JSTARS 
software. 

4.2.7 Future RF Link Requirements, Design and Performance Prediction 

In order for the RPSIDISNIU to be implemented in the future in the E-8C PME, an RF link must 
be established between the AIRNIU (See Paragraph 4.2.2) and the GRNDNIU. This link will 
provide for the transmittal of virtual target data (via entity state PDU) from a ground site 
(designated as the Northrop Grumman laboratory in Melbourne, FL) to an E-8C aircraft in flight, 
and for the transmittal of E-8C PDU from the aircraft to the ground site. In the follow on 
JADSA/^STARS work phases, Northrop Grumman will provide system and software support to 
develop this RF Link Interface. 

During JADS Phase lb, Northrop Grumman supported the Government in running message load 
tests to establish the basic RF bandwidth requirements for the RF link design (see Reference 10). 
Other tests were conducted which confirmed the ability of the GRNDNIU to accommodate the 
receipt of PDUs at rates up to 1100 PDUs per second. This is greater than the bandwidth 
capabilities of a T1 communication service (estimated at approximately 350 PDUs/second). This 
rate also is much higher than the anticipated rate (estimated at less than 100 PDU per second) at 
which PDUs will be issued from DIS or to the aircraft. This was tested by replaying PDUs from 

the SGI logger at various rates and viewing on the OWS display a table indicating the count and 
receipt of PDUs by the GNIU. 

In advance of the planned Phase 2 work, RF link studies also were conducted during the 
development of VSTARS, and resulted in the selection of the E-8C (“Contingency 
Enhancements”) UHF SATCOM system and equivalent ground site SATCOM components as 
the recommended baseline hardware system and software for this link. This recommendation was 
driven by the following requirements: 

• The link not be limited by line of sight considerations; 

• The link should be implemented as much as possible with existing aircraft and ground 
site hardware and software. 


Figure 4.11 illustrates the recommended concept of operation of the DISNIU RF link. Virtual 
target PDUs will be received from the DIS network by the Ground DISNIU in the Alpha 600, 
via the T1 communication service and an Ethernet LAN in the NG ITF. After processing (see 
Paragraph 4.2.2) in the GRNDNIU, the virtual target information will be passed to a ground 
station SATCOM system in the ITF, formatted, and transmitted via the SATCOM RF link to the 
E-8C aircraft. The airborne SATCOM subsystem will extract the virtual target data and pass it to 
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the AIRNIU in the RPSI in the PME, where the data will be processed as described in Paragraph 
0. E-8C ES PDUs will be formed in the RPSI and periodically forwarded to the ground site 
GNIU via the same SATCOM downlink. 


RF LINK INTERFACE 





Figure 4.11 SATCOM Will Provide the RF Link Between the GNDNIU and the AIRNIU 
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4.2.8 E-8C SATCOM System Overview and Study Recommendations 

Figure 4.12 shows the major functional components of the current E-8C “Contingency 
Enhancements” SATCOM hardware suite, as recommended for JADS. Other components in the 
SATCOM suite that are not required for JADS are not shown. The primaiy elements of the 
SATCOM subsystem include a UHF antenna, a Multi-mission UHF Satellite Transceiver, a Data 
Encryption Unit, a SATCOM Processor/Computer, an ALPHA workstation and an OWS LAN 
interface to the Joint STARS Radar System. 


The E-8C SATCOM subsystem currently can provide a secure, over the horizon communications 
link, to transmit navigation and RADAR MTI and S AR data from the aircraft to a ground station, 
as well as to transmit messages from a ground site to the aircraft. The aircraft utilizes two 
different SATCOM systems. It is intended to utilize one of these systems, with modified 
software to accommodate the JADS RPSIRF link requirements in the aircraft. An equivalent 
suite of hardware will be utilized for the ground site portion of this RF link in the Northrop 
Grumman ITF. 



Figure 4.12 Major Hardware Components of the SATCOM Subsystem in the 

E-8C Aircraft 

In addition to the use of this existing SATCOM system hardware, software must be developed to 
accommodate the special requirements of the JADS/RPSI system. During Phase lb, the existing 
E-8C SATCOM hardware, software and operational concepts were reviewed. In current Joint 
STARS operation, SATCOM usage involves communication between the aircraft SATCOM 
station and multiple ground stations. The aircraft operates as the primary station and controls the 
network linking the aircraft to the ground stations. The ground stations are referred to as 
“secondary stations” and are under the control of the aircraft. Control of the ground stations is 
effected by polling by the aircraft station. Associated with this polling is a significant reduction 
in channel efficiency. Most of the data traffic over the network is transmitted from the aircraft 
and the communication protocol design is heavily biased in favor of the down-link traffic. The 
up-link traffic to the aircraft generally is limited to a low volume of data. (See reference 11). 
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For JADS/RPSI the situation is quite different. For JADS, most of the data traffic will be from a 
single ground site to the aircraft, (to convey the DIS ES PDU, at a nominal rate of 100 
PDU/second to the aircraft) .The lesser traffic will be from the aircraft to the ground site, (to 
convey the aircraft ES PDU to the ground site and thence to the DIS network, at a nominal rate of 
one (1) PDU/second, or less). The JADS RPSI does not require the multi-station polling that is 
employed in Joint STARS. By eliminating this polling for the RPSI by modification of the 
SATCOM protocol, significant transmission channel efficiency may be realized. A study will be 
conducted during Phase 2 to determine the best design modifications for VSTARS. 

The existing Joint STARS SATCOM protocol utilizes a Transport Layer application data 
packing format, which is tailored to the current “contingency enhancements” Joint STARS 
application. This transport layer currently can accommodate 600 octets of application data. As 
such, it could accommodate up to 25 stripped (192 bit) PDUs per frame. It is intended that during 
the planned follow on JADS phases the design of the software for RPSI usage of SATCOM will 
be preceded by a detailed review of this existing SATCOM software design. Communication 
protocol, software design, and timing will be reviewed. Then a JADS version can be designed, 
based on a best mix of existing SATCOM software and any necessary modifications to 
accommodate the requirement to link PDUs between the aircraft and the ground site at the 
maximum data rates achievable, consistent with acceptable performance (e.g., data error rates) of 
the SATCOM link. These issues are discussed further below. 

4.2.9 SATCOM Performance Considerations 

During the execution of a JADS/DIS “battle scenario” the number of entity state PDU, which the 
RPSI must receive from DIS, has been estimated at upward to 100 PDUs per second (>19,000 
data bits per second, based on 192 bits/PDU, plus overhead). Although this PDU rate is a 
variable and can be controlled somewhat by judicious design of the scenario, it is desirable to 
design the SATCOM RF link software, and to select the system parameters and operating modes 
to accommodate a PDU rate as high as possible, consistent with an acceptable limit on the 
number of errors in the PDU data. 

A useful measure of goodness for the performance or quality of a communications link is the 
Throughput, e.g., the rate at which data can be transmitted and received at acceptable data or 
message error rates. For the JADS RPSI SATCOM link, performance can be predicted by a 
consideration of the design of the hardware and software of the various SATCOM system 
elements (air, ground and satellite) and of the expected characteristics of the RF transmission 
paths. 

Given the selection of the existing SATCOM system hardware in the aircraft, an equivalent 
SATCOM system at the ground site, and candidate UHF satellites, the SATCOM link can be 
analyzed to provide a link budget analysis. The quality of the link can be expressed in terms of 
the expected signal to noise ratio and the bit error rate (BER) for the total link (i.e., ground site to 
satellite to aircraft). An example is the space link from the ground site at the Northrop Grumman 
ITF in Melbourne, FL, to a selected UHF satellite, and then to the E-8C aircraft flying near Fort 
Irwin in California. Performance can be predicted as a function of the data transmission bit rate. 
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modulation mode (e.g., BPSK, QPSK etc.,), the details of candidate communications protocol, 
propagation conditions, and hardware processing parameters.. 

A preliminary analysis such as this was conducted in Phase lb for a selected UHF satellite (UHF 
Follow -On, UFO @ 100 deg. W longitude), a ground station at the Northrop Grumman, ITF in 
Melbourne, FI. and an E-8C aircraft flying near Fort Irwin, Ca. The results are shown in Table 
4.3. This analysis will be refined in phase 2. For the example postulated parameter set, satellite 
type, locations of the ground based SATCOM system and the E-8C aircraft, this preliminary 
analysis indicates a composite Eb/No=9.09 dB, (ratio of the energy per information bit of the 
input PSK signal to the noise power per Hz.) for the entire link as received by the aircraft.. This 
corresponds to a theoretical BER performance of approximately 2 * 10'^. 

The expected message error rate (e.g., the PDU error or loss rate) can be estimated from a 
consideration of the predicted BER and selected candidate (software) protocols for transmission 
of the PDU, and tfie logic which is employed by the software when bit errors occur. As a result of 
this initial analysis a software design will be selected, implemented, and tested in the Northrop 
Grumman laboratory with SATCOM system components, in order to confirm the results of the 
analysis and/or refine the expected performance. It is intended that the planned follow on JADS 
phase 2 activities will complete this analysis and design and also will include laboratory tests of 
the RF link, utilizing different modulation methods (e.g., BPSK & QPSK variants) and data 
rates, and for different versions of available UHF satellites. 

The results of these analyses, tests and a recommended software design will be reviewed with the 
Customer for concurrence in the design and recommended operating mode. This will provide the 
Customer with an early opportunity to consider tailoring the JADS battle scenario so that the 
PDU rates are selected to be consistent with the capability of the RF link. 
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Table 4.3 Preliminary Analysis of SATCOM Link Budget 


SAfCdM LINK FROM MELBOURNE, FL to AIRCRAFT 
jpAI^UI^iONS near Fort IRWIN, California 


a. NOISE TEMP SATELLITE 
aa. Rain Effects Tr 

b. NOISE TEMP Aircraft TEMP 

c. EIRP SATELLITE MAX 
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f. Rec. WAVELENGTH 

g. REQUIRED Eb/No for 10^5 

h. INDEX MODULATION (m) 

i. I.F. BANDWIDTH 

j. NOISE POWER 
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Terminal 
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1. 

TRANSMIT WAVELENGTH 
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n, 
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dBw 

20 

0. 
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dBi 
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P- 

TRANSMIT EIRP 

dBw 

32 




RECEIVED @ SATELLITE 


q. PATH LOSS XMIT 
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(0 deg. N, 100 deg. W) 
dB 

173.2316 

r. GAIN OF 1 m SO ANTENNA 

dB/m2 

10.84611 

s. MISC LOSSES 

dB 


t. OPERATING FLUX @ SATELLITE 

-132.386 

u. SATELLITE FLUX DENSITY 
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•il-110 

V. INPUT BACK-OFF 

dB 

22.38551 
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dB/k 

ii'4.3" 
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dB 

o’"^' ” 
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dB 

0 
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dB 
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dB 
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z1 Cumulative C/Nu + Lim. 

dB 
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z2.Eb/No — - 

dB.', 

"^31.23911 

zSC/No 

dB 
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Table 4.3 Continued 
aa. EIRPs.sat 


RECEIVED AT AIRCRAFT 
(36.6 deg N, 117 deg W) 

dBw 


bb. B/Oo dB 

cc. A/C Receiver Gain dB 

dd. Gr/T dB/K 

ee. MISC LOSS D/L L' dB 

ff. EIRP attrib. to carrier dB 

gg- C/Nd dB 

hh.Eb/No .. ■ db . 

COMPOSITE C/N CALCULATION 

STEP 1 C/Nu 
STEP 2 C/Nd 
STEP 3 1/(C/Nu) 

STEP 4 1/(C/Nd) 

STEP 5 1/{C/Nn) + 1/(C/Nd) 
gg. COMPOSITE C/N FOR ENTIRE LINK 
hh. Composite Eh/No FOR dB 
ENTIRE LINK „ 


0 

2 

-27'.37i ' 
6 

28.99575 

7.971866 

;'9.118254 

1021.579 

6.268832 

0.000979 

0.159519 

0.160498 

7.945297 

9.091685 
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5. MTI SIMULATION TECHNIQUES 

5.1 Application of MTI Pd and TC Statistics 

This section is intended to detail the algorithms and techniques which were utilized to implement 
the Moving Target Indicator (MTI) probability of detection (Pd) and target classification (TC) 
statistics for the JADS RPSI. The basis of this work was derived from the Phase 1 study for 
integrating a Radar Processor Simulation (RPS) onto the Joint STARS platform. The results of 
the study have been incorporated in reference documents 2, 3 and 4. 

5.1.1 MTI Pd Requirements 

The application of MTI target statistics is fundamentally related to target signal-to-noise ( T/N) 
as derived from the radar range equation modified to include Joint STARS radar subsystem 
specifics. The Engineering Design Report (EDR) (see reference 3), required radar operating 
curves to be developed off line. These relate Joint STARS dwell time, azimuth and range to a 
family of probability of detection (Pa) and T/N levels. The analytical basis of this MTI Pa 
simulation was derived from a Joint STARS radar performance prediction model (JCONT) 
developed under the Full Scale Development (FSD) program. JCONT is a non real-time tool 
which simulates the transmission, reception and processing of a number of coherent processing 
intervals (CPIs) comprising a set of different pulse repetition frequencies (PRFs) of specified 
integration length and azimuth beam spacing used to detect and locate a moving target in a 
clutter background. The target is placed in the desired range and angle location and evaluated 
over a range of radial velocities. For each CPI, the T/N and T/C ratios are determined for each 
Doppler filter by convolving the Doppler filter spectrum against the combined clutter, noise and 
target spectra. From the combined clutter and noise environment, a detection threshold is 
determined that will allow the system probability of false alarm (PFA) to be met. A Swerling I 
target model is used with the detection threshold to determine target Pd for each CPI. Assuming 
each CPI represents an independent look at the target, a composite target Pd is established over 
‘N’ CPIs using an ‘M’ out of ‘N’ detection scheme. 

5.1.2 Target-to-Noise (T/N) vs Pd 

Tests using JCONT indicate that a set of radar operating curves can be developed which 
accurately relate T/N to Pd averaged over target velocity (Figure 5.3). Since the Joint STARS 
radar employs a pseudo low, multiple PRF design, some PRFs may be blind in range. The PRFs 
have been selected such that at most only one PRF will be completely blind in range, so two T/N 
curves have been developed: one with zero blind PRFs and the other with one blind PRF. When 
only a portion of the long pulse is lost during transmission, the desired Pd may be interpolated 
between these two curves. 
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5.1.3 Target Radial Velocity (9?t) vs Pd 

The relationship of % to Pd varies based on the set of PRFs used to reduce the effect of target 
blind speeds near multiples of the PRF. Additional tests using JCONT show that the magnitude 
of Pd dips over % are predictable and vary with or equivalently, average Pd. Since the 
location and magnitude of these Pd dips require an intimate knowledge of the relationship of 
T/N and T/C in a Doppler filter, this type of processing is beyond the scope of a real-time 
simulation. Instead, a reference Pd vs curve has been developed off line for each PRF set so 
that the location of Pd dips are known and their magnitude can be predicted using a range rate dip 
factor to attenuate the dips when average Pd (= T/N) is higher than nominal, and to enhance the 
dips when average Pd (= T/N) is lower than nominal. 

5.1.4 Determination of T/N 

A baseline T/N ratio is defined in dBm consisting of the constant Joint STARS radar system 
gains and losses, from which variable gains and losses based on target geometry and scan 
conditions may be added. T/Nq consists of classified values for the peak transmit power (P,), 
peak antenna transmit gain (GO, peak antenna receive gain (GO, processing gain (Gp), transmit 
duty factor (DO, wavelength (X), thermal noise factor (kT), fixed receive chain losses (Ucv), and 
constant terms [2(47t)^ = 36 dBm]. 

T/No = P, -I- G, + Gr + Gp -I- 101ogio(DO + 301ogio(A,) - kT - Lrcv - 36 

Lmv consists of fixed allocated losses such as radome loss, noise figure, matched filter loss, phase 
noise, SPP noise, Doppler filter taper, A PRF (waveform), and average beam pointing loss. 

T/No is modified based on specific target and scan conditions such as the targets radar cross 
section (aO, Doppler filter bandwidth (Dbw), target range (RO, beam broadening loss (Lscn), 
atmospheric loss (Latm), elevation pattern loss (UpaO, beam spacing (Leo), and lens loss (Liens). 
Each of these losses are computed based on the geometric relationship of the target to the scan. 
They are added to the baseline T/N to obtain the following: 

T/N, = T/No + a, - lOlogio(Dbw) - 401ogio(Rt) - (Lscn + La,m + Lepat + Leo + Liens) 

Other losses which factor into T/Ntsuch as quantization loss, filter scalloping loss, pulse loss 
and CFAR losses vaiy according to PRF and Doppler filter and is therefore compensated for 
through application of the range rate dip factor (9lf). 

5.1.5 Determination of Target Pd (Pdt) 

After modifications to T/N, are made, the target’s average Pj over 91 (AP*) is interpolated from 
the radar operating curves which relate Pj to T/N. From the APo, a range rate dip factor % is 
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computed to determine the actual Pd statistic of the target at its radial velocity 9? and then applied 
as follows to derive the target’s actual Pd (Pdt). 


- 1 + lOlogio ( APdr / APdt ) Pdt = APdt + SRf X ( Pdrt - APdr ) 


where, 

APdr : Pd averaged over 91 for the reference waveform. 

APdt : Pd averaged over 91 for the target interpolated from \ curves. 

Pdrt : Pd for the target from the reference curve at 9tt. 

5.1.6 Computations Made Per 4x4 Km Grid 

A grid filtering technique is used to check for virtual targets within the radar beam footprint by 
first quantizing all virtual targets within grids of 4x4 Km. When the set of 4x4 Km grids within 
the beam have been selected, some pre-processing of MTI Pd statistics are accomplished at the 
grid level. Since this represents very low resolution data, information about this area cannot 
change rapidly with respect to the scan. The computations made per grid are Latm. Lepat» and Liens 
and are applied equally to all targets within the grid. 

Atmospheric loss (Latm) is a significant T/N loss due to the attenuation of the radar energy 
through variable atmospheric conditions. Following the Joint STARS System Specification, there 
are three types of weather conditions modeled: (1) clear air, (2) clouds, and (3) rain. For rain 
conditions, a rain rate in mm/hr is defined. Future implementations of weather PDUs on the DIS 
network will allow for more flexibility concerning weather, but for this phase of JADS, the 
operator specifies one of these weather conditions (Later we might want to consider a graphical 
user interface (GUI) which will allow the operator to define weather regions mapped to grids). 
Latm is the sum of clear air, cloud, rain + cloud and rain losses over which the beam travels both 
ways through the boundaries of each weather strata. The boundaries of weather strata are 
separated by altitudes from which the beams projection through each layer is computed and a 
constant loss (per Km) for each weather strata is applied over twice the distance through the 
layer. The clear air loss is applied for the entire two way propagation path and is currently 
available in subroutine SKRS90_ALOSS. The cloud loss is defined as 0.026 dB/Km (from the 
Joint STARS System Specification) and is applied for the two way propagation length through 
clouds if the weather type indicates cloud or rain conditions. The rain loss is defined from 
Nathanson (Reference 9) as 0.00809rr'where ‘rr’ represents the rain rate in mm/hr. 
Subroutine MTISIM_ATM_LOSS defines the mathematics used to compute these losses using 
platform altitude, latitude, target range, and grid weather as inputs. 

Elevation pattern loss (Lepat) occurs when the target is offset from the antenna elevation boresight 
and is particularly apparent for small targets (such as the double Doppler component of the TC 
mode). Given the platform altitude/orientation and the antenna orientation (A-Matrix), the 
elevation boresight range is computed for the dwell. The range of the grid center is checked 
against a Taylor weighted beam approximating the actual antenna elevation pattern to determine 
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the elevation pattern loss for all targets within that grid. Analysis subroutines TAYLOR 1 and 
SANTVP are utilized to determine Lepat- 

Lens loss (Liens) is a radar refraction loss which makes the atmosphere behave like a negative 
lens, resulting in the reduction of the targets apparent size. Liens is interpolated from a family of 
curves relating grazing angle and target (i.e. grid) range derived from the January 1973 TF.F. F 
paper on Athiospheric Lens Effect. Analysis subroutine LENSLOSS is available. 

Typical losses for a clear weather single swath condition are as follows: 



Figure 5.1 Typical Radar Losses for Clear Weather 
5.1.7 Computations Made Per Dwell 


Some radar system losses vary only as the beam scans in azimuth and can be considered the same 
for all targets within that beam. 

The beam broadening loss (Lscn) occurs from electronically steering the beam in azimuth, and for 
the Joint STARS antenna is represented by the closed form expression: 

Lscn = -201ogio ( 5.67cos° ^0s - 2.36cos9s - 2.31) 

where, 

0s: antenna scan angle with respect to boresight (radians) = 7i - Ps- 
Ps: antenna cone angle with respect to platform heading (radians). 

In the Joint STARS radar design, the Doppler filter bandwidth (Dbw) and azimuth beam spacing 
varies as a function of 0s. The T/N curves were derived under the assumption that a nominal 
Dbw and two-way 6 dB beam spacing were used. The actual Dbw can be derived from the number 
of integrated pulses (Nim) and PRF in the first CPI of the dwell as 

Dbw = ^PRF/(2Ni„t) 
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A beam spacing factor (BSf) can be computed to relate the actual beam spacing back to the two- 
way 6 dB beam spacing. From this factor an additional beam spacing loss (Leo) analogous to the 
azimuth beamshape loss can be derived as follows; 


where. 


Lco = -101ogio(BSf) BSf = (t)d COS0S / <t)b 


(t)d : Beam spacing for the current dwell (radians). 

<t)b; Two-way 6 dB beam spacing at broadside (radians). 


Typical losses for a dwell as a function of angle are as follows: 



Figure 5.2 Typical Radar losses for Dwell vs Angle Computations made per Target 
5.1.8 Computations Made Per Target 

Computations made per target are the lowest resolution required for the MTI Pd simulation. The 
computations made per target are target range (R,), range rate (SRt), radar cross section (Ot), 
terrain screening, and target resolution. 


The loss due to target range is 401ogio(Rt). Target range is given by: 

Rt = [ (Tx - Px)" + (Ty - Py)" + (T, - Pz)" 

where. 


T : Target Position Vector (in TCS) 

P: Platform Position Vector (in TCS) 
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Target range rate (9?t ^ radial velocity) is derived to determine if the target is in a Pj notch due to 
Doppler ambiguities within the PRF set. Since the Pd dips are considered the same for opening 
and closing targets, the absolute value of is used. 

= -Vt • (T - P) / Rt Vt: Target Velocity Vector (in TCS) 

T^get radar cross section (a,) is expressed in dBn, as 101ogio(RCS,) when RCS, is expressed in 
m . a, will be the default value for primary targets in the Joint STARS System Specification For 
TC statistics, the smaller double Doppler Gt is used. 

Target screening occurs when a target is obscured along the radar line-of-sight by a physical 
object. Determination of target screening is done by comparing the target line-of-sight to the 
platform with the target line-of-sight in the Area Visability Database (AVD). Subroutine 
STCAHO_GET_TAN_RTE accesses the AVD and reports back the target line-of-sight to the 
horizon based on the azimuth angle. 

Target resolution effects target detection in range, azimuth and Doppler space. When two or 
more targets are located within close proximity, the radar can only detect one of those targets 
Due to the scanning nature of the Joint STARS MTI design, target resolution constraints in 
azimuth and Doppler space are rare because the target can be seen by multiple CPIs at different 
azimuth angles, so it is not necessary to model these constraints. The primary constraint on 
target resolution is the distance between targets in range. Formal system level tests require a 
target to be at least 1.5 range bins from another target to insure detection capability, but a target 
may be detected when closer. Variable range resolution effects can be modeled by uniformly 
selecting a range resolution based on range bin size between 0.75 and 1.5 range bins for each 
radar dwell. 

5.1.9 Data Analysis 


In order to evaluate this modeling technique, two data analyses have been performed. First, a 
theoretical simulation environmental test was performed to evaluate this technique against the 
non-real time analysis tool JCONT. The second analysis compares the technique with actual 
flight data taken under controlled conditions. 

S.1.9.1 JCONT Simulation 

The advantage of performing a comparison with a theoretical test environment is that all 
conditions can be controlled. In this analysis, 100 test points were randomly selected in range, 
azimuth, and weather, with all other variables set to a nominal value. The average Pd of the real¬ 
time simulation (JADS) is compared with the non-real-time simulation (JCONT). The statistics 
show that the average Pd error is 1.0% with a standard deviation of 1.7% and the average T/N 
error is 0.3 dB with a standard deviation of 0.3 dB. The results are indicated below in Figure 5.3 
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Figure 5.3 Compares Pd v.s. T/N of JADS & JCONT Simulations 
5.I.9.2 Flight Data 

Analysis of flight data requires as many variables as possible to be controlled, but there are 
always unknown system conditions. Formal system level tests are designed to maximize control 
over the variable conditions of the test, so these tests represent the best data set for comparison of 
the JADS simulation to the actual system. A brief comparison between SLPV flight data and the 
JADS simulation is shown below for twelve distinct SLPV Test Points. The JADS estimate of 
Pd assumes clear weather conditions and a nominal sized target with a Swerling I radar cross 
section fluctuation. The chart shows that the JADS estimate of Pd was slightly more optimistic 
than the flight data (on average about 3-4%), which can easily be attributed to errors in the 
assumptions of variable target size and clear weather conditions. 
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Figure 5.4 Compares Pd of JADS and SPLV 
5.2 Application of MTI CEP Statistics 

This section is intended to detail the algorithms and techniques which were utilized to implement 
the Moving Target Indicator (MTI) location accuracy statistics for the Joint Advanced 
Distributed Simulation (JADS) environment on the Joint STARS platform. The location of 
targets detected by the Joint STARS radar are reported relative to the local Topocentric 
Coordinate System (TCS) after coordinate conversion from range and angle. Location accuracy 
IS measured and applied using the Circular Error Probability (CEP) method based on the targets 
reported position versus its true position. 

An overview of the MTI location error sources is provided as background for the JADS CEP 
algorithms. From these error sources, a two dimensional linear model of down range and cross 
range errors relates traditional lo values to target CEP. The down range, cross range, and CEP 
statistics observed during controlled flight tests are then codified to the JADS CEP igorithms 
and applied to the JADS virtual targets based on their true range and angle. 

5.2.1 MTI CEP Error Sources 

The application of MTI target location error statistics is derived from the la errors in range, cone 
angle, vertical separation and coordinates. Range error sources include radar range measurement, 
residual refraction and hardware. Cone angle error sources include interferometric measurement 
and boresight corrections. Vertical separation errors primarily derive from platform altitude and 
the hypsographic database. Coordinate error sources include navigation position and coordinate 
conversion. The geometric parameters outlining the error sources are defined as follows: 


D- 40 





The CEP error sources are input into a linear model with two outputs; a down-range error and a 
cross-range error, where each output is a linear function of individual error contributors. The Ic value 
of the individual error contributors are RSS’d, and CEP is calculated for the uncorrelated down range and 
cross range variables as: 


• X=inin(Xr,Dr) Y=max(Xr,Dr) 

• Linear region: X/Y>0.4: CEP = 0.560Y +0.617X 

• Quadratic region: X/Y<0.4: CEP = 0.674Y + 0.128X + 0.51 SX^/Y 



Figure 5.6 MTI Location Error Model 


The down range error model is be derived from the la individual contributors as shown below; 
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Figure 5.7 MTI Down Range Error Model 



Figure 5.8 MTI Cross Range Error Model 


5.2.2 Data Analysis 

The la down range and cross range errors can be derived from a theoretical model as described 
in the previous paragraph and from flight data taken under controlled conditions. 
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5.2.2.I Location Error Budget 


From the allocated location error budget, target CEP is derived as a function of range and angle, 
and is used as the basis of location accuracy measurement. The following diagram illustrates the 
CEP curves for a 60° scan angle. 



1-Sigma Xr 

-1-Sigma Dr 

- • - - CEP 

X Target 


Figure 5.9 Theoretical Location Accuracy 

Analysis of controlled SLPV flight data provides the best insight into the actual target location 
errors. Controlled test conditions at variable range and angle combinations yield an approximate 
CEP model as a function of range and angle from which the la down range and cross range 
errors may be decorrelated. The following diagram illustrates the CEP curves for a 60° scan 
angle. 


CEP Approximation 
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X Target 


Figure 5.10 Location Accuracy from SLPV Flight Data 

Further analysis of this data shows that there are four variable statistics which contribute to this 
CEP approximation; 

• a location error bias. 
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• a random Gaussian distribution about the mean, 

• a random exponential distribution extending beyond the tails of the Gaussian distribution 
(cross range only), 

• and a uniform random distribution extending beyond the tails of the Gaussian distribution 
(down range only). 

Each of these effects can be seen in the following diagrams. 



Figure 5.11 Distribution of Errors from Flight Data 

JADS simulation routines have been successfully executed against SLPV test points showing 
positive results; ^ 



Figure 5.12 Distribution of Errors from JADS Simulation 
5.2.2.2 Determination of Target Position 

Once the down range and cross range errors have been established for a given range and angle 
combination, these statistics must be applied randomly to determine the reported target location. 
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Analysis of flight data indicates that location errors consist of a variable bias, a Gaussian 
distribution about the mean, and an exponential/uniform distribution extending beyond the 
Gaussian tails. 

To avoid a simulation-like appearance, each of these characteristics must be modeled in the 
JADS simulation. This is accomplished by first forming the fundamental CEP ellipse using the 
theoretical Ic down range and cross range errors for that range and angle condition (as derived 
from flight data analysis). 

• Location Bias: A phasor is used to model the location error bias by slowly moving the 
center of the error distribution inside the CEP ellipse. Through observation of the SLPV 
flight data, the magnitude of the phasor is approximately one fourth of the la value. The 
phasor is incremented each dwell so that all targets within the current dwell have the 
same bias. The phasor’s rotation rate varies randomly per revisit to the RSR. 

• Gaussian Distribution: Further reduction of flight data shows that 95% of the targets are 
Gaussian distributed in the down range component and 80% of the targets are Gaussian 
distributed in cross range component. A uniform random number determines if the target 
is Gaussian according to these percentages. If the target is Gaussian distributed, then a 
Gaussian deviate is formed and applied to the computed la value for that target. 

• Exponential Distribution (Cross Range): If a target is selected to be exponential, then an 
exponential distribution is applied in the region extending beyond 1.5 sigma (uniformly 
positive and negative), so that it dove tails with the Gaussian distributed targets. 

• Uniform Distribution (Down Range): If a target is selected to be uniform, then a uniform 
distribution is applied in the region extending beyond 3.0 sigma (uniformly positive and 
negative), so that it dove tails with the Gaussian distributed targets. 

Once the magnitude of the target’s down range (Edr) and cross range (Exr) error has been 
established, the true TCS position (T) of the target is modified as follows along the radar line of 
sight (T-P): 

Az = Tan-‘[(Ty-Py)/(Tx-Px)] 

P = P+ [D]*[E] [D]= [Cos(Az) -Sin(Az)] [E] = [Edr] 

[ Sin(Az) Cos(Az) ] [ Exr ] 

5.3 Application of MTI Radial Velocity Statistics 

This section is intended to detail the algorithms and techniques which were utilized to implement 
the Moving Target Indicator (MTI) radial velocity accuracy statistics for the Joint Advanced 
Distributed Simulation (JADS) environment on the Joint STARS platform. 

Radial velocity is measured by the Joint STARS radar using a velocity decode algorithm based 
on an “M” out of “N” coherent processing interval (CPI) scheme. Each CPI uses a different 
pulse repetition frequency (PRF) designed such that Doppler blinds and foldovers can be 
mitigated with detection by other PRFs. The radar also reports a radial velocity quality flag 
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indicating that the radar has a high or low confidence in the accuracy of the reported radial 
velocity. The quality flag is based on the number of CPIs used to detect the target (“M”). 

5.3.1 Data Analysis 

Radial velocity quality and error statistics have been derived from data collected under controlled 
conditions during SLPV flight tests. Analysis of controlled SLPV flight data provides the best 
insight into the actual target radial velocity errors that can be modeled for the JADS simulation. 

5.3.1.1 Radial Velocity Error 

Controlled test conditions at variable range and angle combinations show that the reported radial 
velocity contains an error distribution which is independent of range and angle test conditions. 
The data indicates that 93% of the reported targets form a Gaussian distribution about a mean 
generally shown to be 0. The remaining 7% of the targets form a uniform distribution beyond 
2.5a. The uniform distribution appears to have two levels, where approximately 80% of the 
uniformly distributed velocity errors (0.8*7%=5.6% of all detected targets) lie within 15a. The 
wild points ( 7-5.6-1.4% of all detected targets) consistently appear in each controlled test point. 
5.13 illustrates the radial velocity error profile from SLPV flight 049 from which the 

3ADS simulation was derived. The corresponding profile for the JADS simulation results is 
exhibited m Figure 5.14. 


Live Radial Velocity Error - F3-049 



Radial Velocity Error (cm/s) 


Figure 5.13 Distribution of Radial Velocity Errors From Flight Data 
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Figure 5.14 Distribution of Radial Velocity Errors From JADS Simulation 
5.3.1.2 Radial Velocity Quality 

Analysis of the radial velocity quality flag shows that the reported radial velocity quality is highly 
correlated with the probability of detection (Pj) for each of the test points. This seems logical 
since Pd is also based on the “M” out of “N” CPI detection scheme. Therefore the radial velocity 
quality flag should be randomly selected based on the target’s Pd. The radial velocity error 
profile for good quality targets is marginally better than that of poor quality targets. 


I# Frequency - Good Qual 
- Frequency - Bad Qual 


Radial Velocity Error (cm/s) 



Figure 5.15 Distribution of Radial Velocity Errors for Good and Bad Quality Target 
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6. JADS Communications Connections At Northrop Grumman Integrated 
Test Facility (ITF) 


JADS is being developed in multiple phases. The general concept of operation for Phase 1 of the 
Joint STARS JADS project has been as follows: 

• The JADS system was developed in the lab environment on the Alpha 600’s workstations 
These computers receive DIS virtual targets PDUs via a T1 line from White Sands 
Missile Range (WSMR) via Kirtland AFB which is connected to the laboratory setup for 
data monitoring purposes. An SGI workstation is used to log the PDU data files which are 
received over the DIS WAN (Tl). 


• The target/war simulation, JANUS operates at the White Sands Missile Range (WSMR), 

generating virtual targets and issuing Protocol Data Units (PDUs) on the Distributed 
Interactive Simulation (DIS) network. 


• The Radar Processor Simulation Integrator (RPSI), which executes on the Alpha 600’s 
computers, receives the virtual target information, via entity state PDUs which are 
received from the DIS network, or replayed from the SGI workstation. The AT P H A 600s 
are connected to an Ethernet LAN which in turn interfaces with the T-1 line via an DDNX 
and an KIV-7 encryption device. The RPSI supplies virtual target radar reports combined 
with the live target radar reports (MTI and SAR reports) to operator work stations and to 
a SCDL emulation. 


• At present for JADS, a single Tl communications service line is connected into the 
Northrop Grumman Intention and Test Facility (ITF) building 222. This line provides 
for the incoming simulation data (PDUs ) and outgoing messages to and from the TCAC 
at Kirtland AFB. A second T-1 service (currently not in service) was utilized for 
transmitting SCDL data (MTI and SAR Target reports) to, and receiving Radar Service 
Requests (RSR) from an Army ground station module, (GSM or a replica, GSMR), at 
Motorola in Phoenix, Arizona. A third T-1 service (yet to be connected) will be 
connected during the next phase, to establish a link to a GSMR at Fort Hood 


• Connections were established so that the PDU files in the SGI (located on the second 
floor of the ITF, in room 209) can be routed to the ITF Classified LAN which connects to 
the Northrop Grumman Operations and Control Test Laboratory (OCTL) which is located 
on the fourth floor of the ITF. The JSTARS Prime Mission Equipment (PME) is located 
in the OCTL and normally is connected to this LAN. The ALPHA 600 computers can 
also be connected to this LAN. 

• Connections also were established for a third LAN, so that the ALPHA 600 computers 
can be connected to two of the operator workstations (OWS) of the JSTARS PME in the 
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These wiring connections internal to the Northrop Grumman IFF are shown in Figure 6.1. Figure 
6.3 illustrates the connections between and major equipment in the Northrop Grumman ITF and 
in the other DIS facilities utilized by the JADS JTF. 

6.1 Secure Voice Communications 

A direct secure voice communication connection via T1 lines from the Northrop Grumman UF 
in Melbourne, FI to the TCAC in Albuquerque, NM, enables continued direct communication 
between ITF and the TCAC during the execution of planned JADS tests. 

The direct telephone voice communication link utilizes one of the 24 sub channels from one of 
the secure T1 lines which connect between the ITF and the facilities at Albuquerque NM. A 
circuit card ( a Quad Analog Voice Card) was installed in the existing IDNX.. (see Figure 6.1). 
The DDNX functions as a demultiplexer and the circuit card enables the use of one sub channel 
from the T1 channels, for use as the voice phone channel. 

An electronic Voice Signal Converter provides for voice transmission over the multiplexed 
digital data link. 
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Figure 6.1 JADS Communications Connections In Northrop Gr umman ITF 


D- 50 






























6.2 Equipment Description and Utilization 

The following describes the equipment and its use: 

The Alpha 600 workstations are known as “JADSOl” and “JADS02”, Each is equipped with a 
single 333-Mhz CPU. One is equipped with 512 of RAM, the other with 1 GByte of RAM. The 
operating system is DEC Open VMS Version 7.0. The JADS RPSI software executes in this 
equipment. 

The SGI Workstation, known as “grumman”, functions as a DIS PDU logger/replayer and as a 
Video Teleconferencing Device (VTC). 

The two Verilink CSU/DSU devices function as the Channel Service Units / Data Service Units 
for converting the T1 line signals for input into the KTV-? HS crypto devices. 

The two Allied Signal KTV-? HS Crypto devices function as the encrypters/decrypters. 

The Network Equipment Technologies IDNX/Micro 20 device (Part number 01-53405) functions 
as the multiplexer. The IDNX splits the signal coming in from the Northrop Grumman JADS 
system, using the CISCO 7000 software, and routes the outgoing messages according to their 
addressed destinations which are: 

• The SCDL which interfaces with the Motorola GSMR. and, 

• The DIS interface to the JANUS scenario generator at WSMR, NM via the TCAC at 
Kirtland AFB, Albuquerque, NM. 


The Voice Signaling Converter is a RAD Data Systems device ( 290100000G) which enables 
connection of voice equipment to data communications equipment, and provides voice 
transmission over a multiplexed data link. 

6.3 Connections to Provide for Developmental Testing of the TADIL J U Tracker 
Algorithms 

Additional connections were established to accommodate the TADIL-J Upgrade (TJU) program 
software developmental testing of new target tracking algorithms using the JADS RPSI. The TJU 
connections are shown in Figure 6.2. These connections permit the OCTL trellis and associated 
workstations to be connected to the JADS scenario PDU playback assets (the SGI workstation), 
to support the algorithm tests. They also permit an Alpha Station 500 workstation to be 
connected to the JADS scenario playback assets. This workstation is utilized for TJU tracker 
algorithm development and test. In addition the JSTARS PME computer systems in the OCTL 
trellis can be connected to an alternate, isolated network segment which was installed for the 
JADS program. The TJU connections provide the capability to connect the entire trellis OWS 
LAN to the JADS isolated LAN (“D3”) segment. The JADS systems will not be connected to 
their external T1 links when the OCTL trellis mission computers are attached. This is protected 
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by the manner in which the alternate LAN’s are connected (i.e. only the isolated JADS segment 
are available to the trellis; the external segment are accessible to the JADS computers when they 
are off-line from the isolated LAN segment). 

These TJU systems can be connected to each other and to other computer assets by means of the 
isolated JADS “D3” Ethernet network segment in the ITF. Trellis assets may be connected to the 
laboratory OWS LAN or to the isolated JADS LAN segment via the OCTL patch panel area 

housed in the STL. The ALPHA 500 workstation has an alternate patch block installed for the 
alternate, isolated LAN. 

Data link protection is provided by the security approved network supported by the IS department 
and DSSD. Isolation from the external JADS T1 link is provided by a IS/Networks-supplied 
patch panel on the second floor in the JADS asset area. These connections are maintained by the 
NG IS department and DSSD. IS/Networks provide and maintain the network hubs and supply 
data necessary for security approval of network assets. 
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Figure 6.2 JADS Connections for TADIL J U (TJU) Developmental Tests 
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Figure 6.3 Communications Diagram for JADSA^STARS 
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1. Introduction 


The Joint Advanced Distributed Simulation End-to-End (IADS ETE) team has funded Lockheed 
Martin TDS Arizona to develop a Synthetic-Aperture Radar (SAR) simulation that emulates the 
Joint STARS SAR operation. This simulation system is referred to as the Advanced Radar 
Imaging Emulation System (ARIES) and is operationally embedded into Northrop Grumman’s 
Radar Processor Simulation Integrator (RPSI). The RPSI integrates the Distributed Interactive 
Simulation (DIS) environment with a simulated SAR and moving-target indication (MTI) 
capability. This integrated system is known as the Virtual Surveillance Target Attack Radar 
System (VSTARS). 

The development of the ARIES has been designed as a two-phase effort. Phase I of the ARIES 
program identified the system requirements, determined software interfaces between the RPSI 
and ARIES, and identified the process by which to integrate real-world topographical and 
feature databases. This design was presented to the government at the end of Phase I and 
accepted at a formal Acceptance Design Review. Phase n is defined as the implementation and 
testing of Phase I design. This final report covers our approach and performance of Phase 11. 

2. Technical Overview 

The ARIES project utilized a time-phased development approach creating three distinct software 
builds. Each build provided increased functionality and verified that requirements were met. 
This incremental development approach was designed to minimize the integration and 
performance risk associated with emulating a JSTARS SAR by providing feedback from the 
customer in regards to the various stages of the development. 

The ARIES program is an enhancement to the SAR simulation capabilities previously 
demonstrated by the XPATCHES simulation. XPATCHES is a non-real time, high fidelity, 
multispectral simulation tool. ARIES emulates the radar operational parameters of the JSTARS 
SAR sensor in real-time with the added capability of using real-world databases such as DTED 
and DEAD. 

The software development was guided by a prototype approach to determine algorithmic results 
and execution performance levels before detailed code was written. As most of the design was 
graphical dependent, software development tools, such as PV-Wave, were used to assess the 
validity of algorithm development. This instituted an effective methodology for data analysis, 
image processing, and the use of tabular manipulation for record-based data used in real-time 
application and optimization. 

2.1 Technical Approach 

As mentioned previously, ARIES was developed in three successive builds. The following 
sections define the builds and the functionality attained with each one. 
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2.1.1 Build 1 


Build 1 demonstrated the functionality of the shaded modules and solid line interfaces in 
Figure 2.1-1. 


Figure 2.1-1 ARIES system design illustrating modules associated with Build 1. 



The shaded modules and solid lines indicate the software and interfaces that are functional with 
this build. 

The Off-line Pre-Processing Module converts the DTED and DFAD data to the ARIES database 
as defined in the Digital Database ICD. This conversion work was performed by the government 
and provided as GFE. As ARIES is executed in conjunction with other simulations in the RPSI, a 
common database origin must be matched for registry of images. This conversion process 
converts the latitude/longitude coordinates of the DMA databases into the agreed upon 
“topocentric” coordinates of the simulation arena. No other database manipulation is performed. 
The ARIES database contains a 512 km x 512 km “playing field” and is stored off-line on a tape. 

The Internal Database Module consists of the intialization software which handles the loading of 
the databases into memory consistent with an operator chosen subset of the entire 512 km x 512 
km arena. Upon system startup, the initialization software will execute an initialization file 
which contains the Ground Reference Coverage Area (GRCA) parameters (location, width, 
depth), and season, atmosphere, and wind conditions. These parameters are specific to the 
execution of the simulations up to the time they are changed (reinitialized). These parameters are 
changed through an operator interface to the initialization file and may be modified at any time to 
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meet the mission requirements as needed. Based on the GRCA parameters set by the operator, 
the initialization software retrieves the elevation and feature information from the external tape 
and loads it into memory for quick retrieval during executions. 

The Real-Time Processing module includes an RPSI interface and the software image generation 
modules, CSCI-1 Ground Truth and CSCI-2 SAR Image Generation. The RPSI interface 
provides all operational and navigational parameters for SAR processing and, in turn, accepts a 
SAR image upon completion. This interface was tested during Build 1 and can pass and accept 
all radar parameters and images as specified in the RPSI ICD. CSCI-1 directly interfaces with the 
RPSI, and upon receiving a SAR image request, it accepts and parses the operational and 
navigational data received. This message contains the Area of Interest (AOI), sensor parameters, 
and target type, state, orientation, and location. To test CSCI-1 functionality during Build 1, a 
routine was invoked that displayed targets by placing a symbol in their respective locations in an 
image. This image did not contain any SAR information at that time, and was used for target 
placement and I/O verification. The image was then passed to CSCI-2 which, in turn, sent the 
image back to the RPSI, verifying the interface functionality between the RPSI and CSCI-2. 

Build 1 consisted of the delivery of the first draft elevation and feature database modifications 
from WSMR, the initialization software, and all software necessary to integrate and test system 
and software interfaces. 

2.1.2 Build 2 

Build 2 demonstrated the functionality of the shaded modules and solid line interfaces in 
Figure 2.1-2. 

Build 2 provided a preliminary SAR output image. The simulation software generates an image 
that contained a subset of the required features and targets. The SAR image is based on feature 
data contained in the GRCA. Targets, previously designated by symbols in Build 1, have their 
SAR signatures inserted into the imagery. Build 2 utilizes portions of CSCI-1 Ground Truth, with 
the added capability from CSCI-2 SAR Image Generation, to produce the preliminary SAR 
output image.Build 2 utilizes the development of support libraries, required for ARIES SAR 
image emulation, as identified in Figure 2.1-2. The ARIES library contains the SAR 
representation of selected terrain textures, manmade and cultural features, target signatures, and 
tabulated mathematical functions. These allows efficient look-up of tabulated data rather than 
time-consuming calculations where real-time performance is mandatory. Terrain textures 
include features such as gravel, sand, and rocky flats. Manmade features include buildings, oil 
storage tanks, and power lines. Terrain textures and features are based on sample JSTARS 
imagery, when available and are used in the testing activity at the program end. XPATCH 
Target signatures were not deemed necessary due to the resolution of the JSTARS sensor. 
Targets were extracted from real imagery and based on their spatial distribution, were recreated 
to emulate real signatures for use in ARIES. Function libraries are used for mathematical 
efficiency and include tabular functions and precomputed weighting factors used in image 
processing. 
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AiMustrating Build 2 completed modules. 

All interfaces between modules are working and the first subset of the ARffiS library has been released. 

pCI-1 generates a ground truth for the SAR scene. This ground truth is a point map for locating 
eatures and targets in the image, and contains all elevation data necessary for the 3-D 
processing effects that are performed in CSCI-2. In this build, CSCI-1 loads the GRCA elevation 
and feature data and rotates it into the line-of-sight. The elevation data, previously stored at low 
resolution, will be upsampled to the sensor resolution. All the CSCM processed data is stored in 
a structure referred to as a point map and is passed to CSCI-2 for SAR processing. 

CSCI-2 accepts the point map generated in CSCI-l and performs a 3-D to 2-D projection. The 
height parameter on the 3-D topopphical and feature data is used to generate obscuration, 
shadows, and surface gain reflectivity. This parameter calculates edge reflectivity effects due to 
the dihedral geometiy created by two adjacent surfaces of differing heights. The gain is a 
function of surface geometry and material parameter. Once the gain and shadow map is 
complete, the SAR targets, textures, and features are inserted into the image. The textures and 
features are modulated by the gain map, thereby ensuring that features are not inserted where 
there is obscuration or shadowing. Moving targets are inserted last in the image, as their velocity 
^fects location and sipature. The combined gain map and features produce an image referred to 
ere ^ a raw SAR image, ie., this image has had only geometric processing performed on it. 
The final step to simulation is applying image processing on the raw image. The insertion of 
features and textures requires the blending of edges, seams, and boundaries. This process 
requires a filtering procedure to spatially correlate each feature to another. 
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2.1.3 Build 3 


Build 3 demonstrated the functionality of the shaded modules and solid line interfaces in 
Figure 2.1-3. 



Figure 2.1-3. ARIES system design illustrating completed modules. 

The complete set of features have been integrated into the library and CSCI-1 and CSCI-2 are 
fully functional having complete image processing capability. 

Build 3 produces the complete ARIES SAR image generation capability. Build 3 integrates the 
completed CSCI-1 and CSCI-2, and the full set of features supported by ARIES. Acceptance 
testing at the completion of this effort was conducted to verify conformance with the Software 
Requirement Specifications and the customer submitted Acceptance Test Procedure. Results of 
those tests are in the Acceptance Test Section 5.0. 

3. Software Design 

3.1 Software Architecture 

As ARIES was implemented in a prototype development environment, the design was revised as 
implementation progressed. The new ARIES software architecture is best represented as four 
distinct modules: Initialization, Ground Tmth, SAR Generation, and Support. Initialization and 
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Ground Truth comprise CSCI-1 and SAR Generation and Support comprise CSCI-2. Table 3.1-1 
represents the software structure, module file names, and functional description. Execution 
begins when the Initialization module is called to setup the memory structures required for 
execution. The Ground Truth module provides the entry point for the real-time image generation 
software. The SAR Generation module is invoked by the Ground Truth module which then 
returns the image and status to the calling routine. Execution within the CSCI, through the 
CSUs, is basically a linear procedure as listed in Table 3.1-1. Each CSCI main module contains 
initialization entry points called by the Initialization module. 

Table 3.1-1 Software Structure, Module File Names, and Functional Descriptions 


CSCI/CSC/CSU 

Module Nam 

Initialization (CSCI-1) 

init_main 

Read .INI 

init_ini 

Read Features 

init_feature 

Build Search Tree 

init_tree 

Merge Features and Tree 

init_merge 

Ground Truth (CSCI-1) 

gmd_main 

Setup Calculations 

gmd_setup 

Transform Targets 

gmd_targets 

Extract AOI Features 

gmd_feature 

Process Elevation Data 

gmd_elev 

Create Ground Truth 

gmd_truth 

Draw Point & Linear 

gmdjine 

Features 


Draw Area Features 

gmd_area 

SAR Generation (CSCI-2) 

sargen_main 

Elevation Textures 

sargen_fractal 

Shadow Projection 

sargen_shado 

Reflective Gain 

w 

sargen_gain 

Texture Application 

sargen_texture 

Target Insertion 

sargen_targets 

Image Processing 

sargen_image 

Noise Processing 

sargen_noise 

Image Output 

sargen_output 

Support (CSCI-2) 

none 

Common Functions 

supp_funcs 

Data Logging 

suppjogging 

Complex Numbers 

supp_complex 


i Description 

Upper level control. Read elevation data, crop to 
GRCA. 

Read aries.ini file and parse parameters. 

Read feature data file and crop to GRCA. 

Create empty search tree structure. 

Parse features in to search tree. 

Initialize structures. Upper level control flow. 
Extract RPSI data and initialize parameters. 
Transform target data to AOI coordinate system. 
Extract feature data that is contained within the 
AOI. 

Extract and interpolate AOI elevation data. 

Draw AOI features into point map. 

Draw point and linear feature types. 

Draw area feature types. 

Read library. Upper level control flow. 

Apply dune and fractal elevation textures. 

Project shadows onto shadow mask. 

Compute gain returns for each point. 

Apply textures to image combined with gain. 
Insert target chips and smears into image. 

Apply filtering algorithms. 

Apply noise and shadow mask. 

Convert complex image to pixel output. 

n/a 

Common support functions. 

Debug data logging utilities. 

Complex number operations for C. 


E-12 



3.2 Supported Features 

Table 3.2-1 lists all features supported by ARIES and how those features are implemented. 


Table 3.2-1 Features Supported by ARIES 


Description 

FID 

Type 

Ground Truth Implementation 

SAR Image 
Implementation 

Dual hiways with medians 

250 

Linear 

Dual Line, width, elevation of - 
0 .01m 

Dark 


251,252,255 

Linear 

Line, width, elevation of -0.01m 

Dark 

Fair Weather, loose or light 
surface road 

253 

Linear 

Line, width, elevation of -0.01m 

Dark 

Cart track, trail 

254 

Linear 

Line, width, elevation of -0.01m 

Dark 

Airport Runway and 

Taxi ways 

706 

Linear 

Line, width, elevation of -0.01m 

Dark 

Storage Tanks - General 

801 

Point 

Single Point 

Chip w/o profile 

Soil 

902 

Area 

Fill 

Smooth 

Sand dunes 

907 

Area 

Fill with dune elevation texture 

Smooth 

Smooth, solid rock 

910 

Area 

Fill 

Fine 

Rocky, rough surface 

912 

Area 

Fill 

Course 

Dry Lake 

913 

Area 

Fill 

Smooth 

Cleared ways 

916 

Linear 

Line, width, elevation of-0.01m 

Smooth 

Walls 

922 

Linear 

Line, width, edge, fill, elevation 

Dark/Smooth 

Fresh water 

940 

Linear/Area 

Line+width or Area, elevation of - 
0 .2m 

Dark 

Canal 

947 

Linear 

Line+width, elevation 

Dark 

Non-perennial stream 

945 

Linear/Area 

Line+width or Area, elevation 

Dark 

Depot 

778 

Area 

Fill 

Smooth 

Packed sand & gravel 

906 

Area 

Fill 

Fine 

Loose Sand 

917 

Area 

Fill 

Smooth 

Dry Depression 

918 

Area 

Fill 

Smooth 

Wadi 

919 

Linear/Area 

Line+width or Area, elevation 

Smooth 

Salt Marsh 

908 

Area 

Fill 

Dark 

Salt Rats 

934 

Area 

Fill 

Fine 

Flood Plain 

914 

Area 

Fill 

Dark 

Power Trnsmssn Twrs 

540 

Point 

Single Point, elevation (lines 
between) 

Chip w/o profile 

Electric Power Lines 

541-544 

Point/Linear 

Line, one point wide 

Impulse 

Communications Twrs 

501 

Point 

Single Point, elevation 

Chip w/o profile 

Date Palm 

957 

Point 

Single Point 

Chip w/ profile 

Revetment - Soil/sand/dirt 

981 

Linear 

Line, width, elevation 

Fine 

Levee 

921 

Linear 

Line, width, elevation 

Fine 

Berms 

982 

Linear 

Line, width, elevation 

Fine 

Escarpment 

924 

Linear 

Line, width, elevation 

Smooth 

Table 3.2-1 Features Supported by ARIES (cont) 
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Description 

FID 

Type 

Ground Truth Implementation 

SAR Image 
Implementation 

Chain link Fence 

927 

Linear 

Line, one point wide 

Impulse 

Barbed wire Fence 

983 

Linear 

Line, one point wide 

Impulse 

Concertina Fence 

984 

Linear 

Line, one point wide 

Impulse 

Irrigated Field 

958 

Area 

Fill 

Dark 

Ditch 

985 

Linear 

Line, width, elevation 

Fine 

Trench 

986 

Linear 

Line, width, elevation 

Fine 

Oil Wells 

103, 474 

Point 

Single Point, elevation 

Chip w/o profile 

Palm Tree 

551 

Point 

Single Point 

Chip w/ profile 

All Buildings 

104, 120, 130, 
138, 160, 180, 
181, 182, 184, 
222, 290, 301, 
324,401,420, 
430, 451,530, 
601, 604, 620, 
630, 650, 680, 
701, 770, 822, 
824, 861 

Point 

Building, edge, fill, elevation 

Dark/Smooth 

Pipelines 

281 

Linear 

Line, one point wide, Orientation 

Impulse 

Railroad tracks 

206 

Linear 

Line, one point wide. Orientation 

Impulse 

Quarries 

102 

Area 

Fill 

Course 

Bridges 

260 

Point 

Length, Width, fill, Elevation of 
comer 

Impulse 


3.3 Supported Targets 


The following list represents the targets supported by ARIES for VSTARS 

ARMORED PERSONNEL CARRIERS - WHEELED 

BRDM-1 

BRDM-2 

BTR-60P 

ARMORED PERSONNEL CARRIERS - TRACKED 

BMP-2 

BMP-1 

MTLB 
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TRUCKS 


M-35 

HMMWV 

M-49A2C 

UAZ Jeep 

AAGUNS 

ZSU-23-4 

SA-13 

Long Track Radar 
TOWED GUNS 
D-30 
T-12 

MULTIPLE ROCKET LAUNCHERS 

BM-21 

BM-22 

TANKS 

T-54 

T-55-T-72 

SELF PROPELLED GUNS 

251 

252 

HELICOPTERS 
MI-8 HIP 
MI-24 HIND 
M-28 HAVOC 
TELS 
SA-6 
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4. System Performance 

4.1 Objectives 

4.1.1 Database Driven 

The objective of the ARffiS simulation tool is to model a JSTARS SAR sensor in a which the 
image content directly correlates with the real world, and the operational and navigational 
parameters implemented in the simulation are those of an actual aircraft during data collection. 
To model the real world, also referred to here as ground truth, a terrain database is needed to 

describe the surface topology and a feature database is required that describes the features that lie 
within the terrain. 


The databases that were implemented for ARIES were DMAs DTED Level I and DEAD. The 
terrain database has a significantly courser resolution than the SAR sensor as DTED Level I 
consists of 100-meter elevation posts. For a typical SAR image, this equates to approximately 20 
elevation posts used to describe the ground in cross range and 40 elevation posts used to describe 
the ground in range. Because as the SAR sensor has a much finer resolution, this creates a major 
discrepancy between the ground truth description and and the amount of detail the virtual SAR 
needs to create a redistic image. ARIES handles this problem by first performing an 
interpolation in both directions using the real elevation data and, secondly, overlaying a finer 
elevation grid that is representative of the terrain type on which the image is being created. As an 
example, a mountainous terrain would have a largely varying elevation grid applied and, 
likewise, a desert terrain would call for a smoother and finer elevation grid. This methodology 
brought a visual reality to the images that was not evident when just using DTED alone Does 
this accurately represent the real world to the resolution of the sensor? - only as a first 
approximation, but no database exists at this time that does. Because no images were provided 
of Southwest Asia at the operational parameters of the VSTARS system, the “look” of the terrain 
IS a subjective matter, largely based on the imagination of the developer. 

4.1.2 Real-Time Processing 

A requirement was placed on the ARIES simulation to produce an image in real time which is 
defined as the time for the real sensor to collect and process data. The real-time processing was 
to be performed on a DEC Alpha 600 single processor that has one Gigabyte of RAM. 
Originally the display image size was given by Northrop Grumman to be 1024 pixels x 512 
pixels. This image display was increased as more information was provided throughout the 
design process to a final image size of 1632 x 1024. The image dimensions had grown by a 
factor of four (we process internally to a power of two thus creating a 2048 x 1024 image , then 
cropping to the required 1632 x 1024) but the image generation timeline had only increased by a 
factor of 1.8 - acceptable with respect to the requirements. The timeline, had the image size 
remained the original, would have been satisfied with seconds to spare. The real-time image 
generation issue guided the majority of the ARIES design. Much of what could have been 
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processed or generated during execution was skillfully created ahead of time and implemented 
using tabular data and libraries. 

4.1.3 Image Quality 

The performance of the ARIES system is measured against the performance of the real JSTARS 
SAR sensor. It is the objective of the simulation to emulate the effects of a real SAR sensor, not 
that of a real processor. Much of the SAR effects that are visible in radar images are due to the 
physical attributes of the terrain and features that are illuminated. Other factors include the 
electromagnetic scattering properties of the features, the operational parameters of the sensor, the 
navigational parameters of the aircraft, and the image processing techniques used to visually 
optomize the images. To evaluate all these factors and their effects on the images, real imagery 
was requested from Northrop Grumman that would be used as a sample for development 
purposes. It was necessary to provide images that contained the same type of operational and 
environmental conditions as would be present in the VSTARS simulated scenarios. The 
following paragraphs describes the images provided by Northrop Grumman and the VSTARS 
scene requirements that either did or did not match those of the sample images. 

The terrain used for the VSTARS is in Southwest Asia, therefore it was imperative, as a 
minimum, that the sample imagery provided by Northrop Grumman be that of desert terrain. The 
radar operational parameters used to collect the data are also of significance in the example 
images, because the terrain and features varied dramatically under various depression angles, 
squint angles, aperture times, and ranges. It was for this reason that Lockheed Martin TDS 
Arizona requested the complex data output of the real processor. This data would have provided 
the necessary absolute values on dynamic range, target-to-clutter ratio, and background noise 
levels. The complex data was not provided and, therefore, the simulation development largely 
comprised analyzing the intensity and spatial distribution of byte scaled, histogram equalized 
images. 

Most visual evaluations performed after final system integration on the background terrain gave 
positive feedback. Most evaluators asked if the images were simulated or real - which proved to 
be the best compliment to the realism. Two evaluators differed greatly on their assessment of 
what was “wrong” with the background. One evaluator thought the terrain was too sharp and 
thereby created too much contrast in the image. Another evaluator thought that there was not 
enough contrast and the background needed much larger hills and valleys. The conclusion made 
by Lockheed Martin TDS and the customer - without the proper data supplied by Northrop 
Grumman to support these image evaluations and their subjective content, the quality and realism 
are left to the individual viewer. The image quality was deemed acceptable by the customer’s 
requirements. 

4.2 Sample Imagery 

The following section contains simulated imagery that was processed through the RPSI 
following the final installation at Northrop Grumman. 
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Th ^ Obtained from an operator 

wort^f- image IS chosen by viewing the hyposographic data on the operator 

workstation, clicking in on the earth coordinates that lie within the radar coverage area and 
initiating an RSR. This interface is a mock-up that the operator uses on the aircraft Workstations 
Moving stationaiy targets are supported by passing target information from a DIS link 
through the RPSI and parsing it to ARIES via a target file. This file contains the reference 
mformation required to locate and process targets within the SAR image. The hypsographic data 
IS overlayed onto the images and is evident by the lines passing through or outlining some of the 


This image represents several successive merged data collections. The features present in these 
coHections are a road traveling NW to SE as well as several rivers meadering through the image 
The roads and rivers are represented by the hypsographic overlay. The lines and features Ic 
slightly offset due to Circular Error Probability (CEP) applied to each SAR image 
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This simulated image is data collected over a dune region. 
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This simulated image is several successive data collections merged together for display purposes. 
The dark feature that forks is a river bed. The hypsographic overlay displays the ground tmth for 
all the offset example cultural features present image. Grey lines follow the roadways CEP is 
evident in the registration of the last image with the previous one. 
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This image is an example of background terrain with a road running SW to NE. The granularity 
and variation of the background are due to the low grazing angle that the sensor operates at. At 
these angles, the smallest changes in the earth’s surface produce high contrast variation in the 
image. 
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This image contains a river bed, concrete levy, bridge, buildings, and a road. The large building 
viewed above the river is a representation created from DFAD data that is not accurate enough to 
adequately describe the structure. Many DFAD buildings are described as omnidirectional and 
extremely large. They are, in actuality, a complex of many buildings all having various heights 
and orientations. The government will be “fixing” DFAD to better describe these type of 
structures. ARIES relies on the database to be correct for accurate representation. 
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This image represents a salt flat feature. The courseness of the surrounding terrain next to the 
salt flat is evident by the high contrast variation viewed in the image. The smoother, finer areas 
represent the actual salt flat. The flats themselves are geometric in shape and were probably man¬ 
made along the edges. A road is evident running through the center of the image, as is a building 
that appears as a bright specular response in the center. 
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5. Factory Acceptance Testing 

A test suite of images has been established as the baseline regression and factory acceptance test 
for the ARES product. Each ARES requirement is mapped to at least one test image which 
demonstrates ARES ability to support that requirement. Additional test cases are provided to 
validate system performance and accuracy. 

5.1 Requirements versus Test Cases 


Table 5.1-1 defines all ARES requirements and maps each to a test case. The test cases are 
described in the table that follows. All test cases have been run and the images, FK) (Feature 
Identification) maps, shadow maps, gain maps (based on geometry and reflectivity of the surface) 
and other output information examined to verify accuracy. 


Table 5.1-1 ARIES Requirements 


Reg # Test # Requirements 


100 1 
no 2 

120 3 


ARES will simulate a JSTARS SAR image in real-time on a DEC Alpha 

600/533 workstation as specified in the Classified Appendix 

ARES shall implement an earth curvature corrected coordinate system. 

ARES shall simulate a fixed image size with dimensions of 2 km x 4 
km. 


130 3 

140 4 

150 4 

160 4 

170 

190 2 

200 4 

210 4 

220 4 

230 4 

240 


ARES shall simulate an image with constant resolution in range and 
azimuth. 

ARES shall simulate images in the slant plane. 

ARES shall generate a magnitude simulated image. 

ARES shall simulate leading edge effects. 

ARES shall simulate the effects of range layover. 

ARES shall simulate the effects of obscuration along the sensor line-of- 
sight. 

ARES shall simulate a single look capability. 

ARES shall simulate a focused Spot SAR. 

ARIES shall simulate depression angles up to 12 degrees relative to 
horizon. 

ARES shall simulate a maximum squint angle of +/- 60 degrees off 
broadside. 

ARES shall simulate summer seasonal conditions. 


250 


ARES shall simulate clear atmospheric conditions. 


260 6 
270 4 

280 4 

290 4 


ARES shall simulate calm wind conditions. 

ARES shall simulate SAR imagery in accordance with JSTARS sensor 
performance parameters. 

ARES shall simulate X-band. 

ARES shall simulate HH polarization. 
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300 

3 

ARIES shall simulate a single resolution in range and azimuth as 
specified in the classified appendix. 

320 

2 

ARIES shall use an elevation database for simulating topographical 
effects within a simulated image. 

325 

8 

ARIES shall support an elevation database which encompasses an area 
up to 512 km X 512 km. 

330 

4 

ARIES shall use a feature database to locate natural and cultural features 
within a simulated image. 

340 

2 

ARIES shall accept earth curvature corrected elevation data from the 
GEE database. 

350 

2 

ARIES shall accept earth curvature corrected feature data from the GEE 
database. 

360 

4 

ARIES shall accept point feature data. 

370 

4 

ARIES shall accept linear feature data. 

380 

26 

ARIES shall accept areal feature data. 

390 

n/a 

ARIES shall incorporate effects of features and topography which lie 
outside of Area of Interest (AOI) that influence obscuration within the 
AOI. 

420 

8 

Rocky flats (maximum boulder size of 1 foot) 

430 

9 

Packed sand and gravel 

440 

4 

Loose sand 

450 

10 

Windblown dunes 

460 

11 

Dry depressions with sandy bottoms 

470 

12 

Wadis 

480 

13 

Escarpments 

490 

14 

Salt marshes 

500 

15 

Salt flats 

510 

16 

Elood Plains 

520 

4 

Date palm orchards 

530 

17 

Irrigated fields 

540 

4 

Buildings 

550 

4 

Cylindrical storage tanks 

560 

4 

Oil wells 

570 

2 

Above ground pipelines 

580 

18 

Soil/sand/dirt berms referred to as revetments 

590 

19 

Below ground sand/dirt trenches 

600 

4 

Above ground concrete and dirt bunkers 

610 

19 

Sand/dirt ditches 

620 

4 ■ 

Paved roads 

630 

20 

Unpaved roads 

640 

21 

Loose dirt trails (less than 1 road width) 

650 

2 

Railroad tracks 

660 

4 

Airfields - composed of buildings and runways 

670 

4 

Transmission towers - 4 sided pyramidal 
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680 4 
690 22 

700 23 

710 19 

720 2 

730 24 

740 2 

750 2 

760 2 

770 2 

800 4 

810 4 
830 4 

840 4 

850 4 

860 4 

870 4 

880 4 

890 4 

900 4 

910 4 


Electric power lines 

Dirt and concrete dikes and levees 

Dirt and concrete walls and berms 

Anti-tank ditches 

Pipelines within trenches 

Quarries 

Chain link fences 
Concertina fences 
Barbed wire fences 
Bridges 

ARIES shall simulate moving targets. 

ARIES shall simulate stationary targets. 

Tanks, ie. T-72, T-72 w/plow, T-72 w/mine roller, T-54/55 
Air Defense Systems, ie. Long Track Radar, MTLB, ZSU-23-4 
Armored Personal Carrier, ie. BMP-1, BMP-2, MTLB 
Artillery, i.e. 2S1,2S3 

Armored Cars, ie. BRDM w/machine guns, BRDM w/AT-5s, BTR-60 
BTR w/120mm mortars. 

Artillery, i.e. BM-21, BM-22, D-30, T-12 

Support Trucks, i.e. UAZ-469, 5-Ton CAC, 5-ton fuel, 2 l/ 2 -ton cargo 
MI-24 ^ 

MI-8 Hip 


920 

930 

940 


950 

960 

970 

980 

990 

1000 

1010 

1020 

1030 

1040 

1050 

1060 

1070 

1080 

1090 


4 HAVOC 

4 ARIES shall support TEL targets. 

b2.1 ARIES shall simulate SAR imagery in accordance with data provided 
through an interface with Northrop Grumman's RPSI as specified in the 
ARIES-RPSI Interface Control Document. 

b2.1 All coordinates passed to ARIES through the RPSI shall be relative to a 

topocentric coordinate. 
b2.1 Area of Interest Centeroid (x,y,z) (m) 

b2.1 Resolution (m) 

b2.1 Wavelength (m) 

b2.1 Dwell Time (s) 

b2.1 Azimuth extent (radians) 

b2.1 Range extent (m) 

b2.1 Sensor position (x,y,z) (m) 

b2.1 Sensor velocity vector (m/s) 

b2.1 Antenna orientation vector 

b2.1 Number of targets within image 

b2.1 For each target in the image area. Target category, ie. tank, truck, 
launcher 

b2.1 For each target in the image area. Target subcategory, ie. M-1, M-60 

b2.1 For each target in the image area. Target specifics 

b2.1 For each target in the image area. Target position centroid (x,y,z) (m) 
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1100 

b2.1 

For each target in the image area, Target velocity vector (m) 

1110 

1120 

b2.1 

For each target in the image area, Target orientation vector 

For each target in the image area, target appearance 

1170 

b2.1 

ARIES software shall execute on the Alpha 600 5/333 workstation. 

1180 

b2.1 

LM shall have 1GB of RAM on the Alpha 600 5/333 dedicated to ARIES 
during simulation activity. 

1190 

b2.1 

ARIES executable software and resident operating system shall have 
access to 100% of the processing resource CPU time on the Alpha 600 
5/333 during simulation activity. 

1200 

1 

ARIES software shall execute under Open VMS, version 6.2 or later. 

1210 

1220 

b2.1 

ARIES software shall be compatible with the RPSI environment. 

ARIES software shall return a pass status upon successful completion of 
image generation. 

1230 

b2.1 

ARIES software shall return a fail status upon unsucessful completion of 
image generation. 

1260 

b2.1 

ARIES shall pass image data to the RPSI with 2000/R pixels in cross¬ 
range by 4000/R pixels in range where R is the resolution parameters in 
meters passed by the RPSI. 

1300 

b2.1 

ARIES software shall accept a Ground Reference Coverage Area 
(GRCA) as input from the RPSI as specified in the ARIES - RPSI 
Interface Control Document. 

1310 

b2.1 

ARIES shall simulate an image which is completely encompassed by the 
GRCA boundaries. 


5.2 Test Cases Defined 


Tables 5.2-1 defines the test cases and describes what each test case involves. 

Table 5.2-1 Test Care Description 

Test Title Description 

# 

1 Alpha Execution Run alpha test program on both the SUN and the alpha 

with default values to generate an image output file. 
Verify the image from the alpha matches the same image 
generated on the SUN. This image is generated using the 
small library, small DEAD and small GRCA. 

2 Terrain / Shadow / Output is the shadow map from 8 different angles of the 
Feature Verfication same terrain. Print and align the maps to verify terrain 

matches in all. AOI is at 0, 0. Final image contains 
artificial features used for quality verification. These 
image contains a feature of known height in known terrain 
at known depression angles. Verify shadow length. 

3 Resolution Compare with test #2 for different resolution in X and Y. 

Distortion 
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4 


5 

6 

7 

8 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


19 

20 
21 


22 

23 

24 

25 

26 


27 


General 

Quality 


Terrain / 
Matching 


Image Generate airport scene and verify image quality of 
contained features. Print out feature maps and align to 
verify constant location of features. Image contains all 
target types and moving targets. 

Feature Print the gain and the feature maps and overlay to verify 
match between the two. 


Windy 
GRCA Test 


Run only the first few images and compare the windy 
palm trees with the calm palm trees in test 4. 

Different sizes and shapes of GRCA's in different ARIES 


of the database. Verify features and terrain. 

Coarse + Smooth Image shows the coarse texture contained within the 
Textures + Stream + smooth texture background. 

Mnt. 


Fine + Smooth Image shows the fine texture contained within the smooth 
Textures texture background. 

Dunes + Smooth Image shows an area of sand dunes within the smooth 
texture background. 

Dry Depression Sample image of feature and other missing items 

Wadi See test 11 

Escarpments Sample image of feature 

Salt Marshes Sample image of feature 

Salt flats + Pipeline Sample image of feature 

Flood Plains Sample image of feature 

Irrigated fields See test 11 

Soil/sand/dirt berms See test 11 

referred to as 


revetments 

Below ground See test 11 
sand/dirt trenches 

Unpaved roads + Sample image of feature 
Ocean 

Loose dirt trails Sample image of feature 
(less than 1 road 
width) + Dry Lake 

Dirt and concrete Also includes orchards, power plants, telephone poles and 
dikes and levees wires and a real bridge! 

Dirt and concrete Sample image of feature 
walls and berms 


Quarries 
Divided Hiway 
Area Features 

Timing 


Sample image of feature 
Sample image of feature 

This is a set of artificial area features designed to 
challenge the area feature routines. Print the FID maps 
and verify alignment. 

Run a set of images on sarsim using a complete but 
reduced library to assess actual timing. 


E-28 



28 

Odd angles 

General test at odd angles, compare FID maps with those 
from test 4. 

29 

Linear 

Test pattern of linear objects. 

30 

Runways 

Dual runways 

31 

Orchards 

Orchard areas. 


5.3 Real Time Processing Predictions 

Table 5.3-1 illustrates the allocated and projected image processing times. The projected 
execution at NG was 32.7 seconds. The actual execution time for the same image was 24 
seconds. Execution time will vary depending on image contents. During build 3 delivery at NG 
reliable execution times as high as 30 seconds were noted. This is all still below the projected 
time. 


Table 5.3-1 Allocated and Projected Image Processing Times 



Allocated 

Timing Predictions 

Actual Times 

CSC 

% 

Target 

Sun Ultra 1 

Actual 

Predicted 

Predicted 

% 



Host 

Timing 

Timings 

vs Actual Host 




Times 

Allocation 

on Sun Timing 

Execution 




Required 

based on 

Ultra 1 

Differences Times 





Build 2 


on Sun based on 





benchmark 


Ultra 1 

Build 2 

benchmark 




20.00 

22.14 

48.70 

90% 

44.00 


Process RPSI Data 

0.00% 

0.00 

0.00 


0.00 

0.00 

0.00% 

External Obscuration 

5.00% 

1.00 

1.11 

• ■= • ' 

1.11 

0.00 

0.00% 

Transform AOI 

5.00% 

1.00 

1.11 


1.11 

0.00 

0.00% 

Generate Point Map 

25.00% 

5.00 

5.53 

8.00 

-2.47 

7.23 

22.11% 

3D to 2D Projection 

15.00% 

3.00 

3.32 

2.00 

1.32 

1.81 

5.53% 

Chip & Texture 

15.00% 

3.00 

3.32 

7.00 

-3.68 

6.32 

19.34% 

Final Image Proc. 

35.00% 

7.00 

7.75 

15.47 

-7.72 

13.98 

42.75% 

Image Output 

0.00% 

0.00 

0.00 

3.72 

-3.72 

3.36 

10.28% 

Totals 

100.00% 

20.00 

22.14 

36.19 

-14.05 

32.70 

100.00 

% 

Initialization 




300.00 " 


271.05 



Table 5.3-2 uses the measured execution times from the SUN scaled to the original image size of 
1024 X 512 pixels. The projected execution time here is well within the time allotment when 
processing this size of image. 
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Table 5.3-2 Measured Execution Time from SAR 



Allocated 

Timing Predictions 

Actual Times 

CSC 

% 

Target 

Sun Ultra 1 

Actual 

Predicted Predicted 

% 



Host 

Timing 

Timings 

vs Actual Host 




Times 

Allocation 

on Sun Timing 

Execution 




Required 

based on 

Ultra 1 

Differences Times 





Build 2 


on 

Sun based on 





benchmark 


Ultra 1 

Build 2 

benchmark 




20.00 

22.14 

48.70 

90% 

44.00 


Process RPSI Data 

0.00% 

0.00 

0.00 


0.00 

0.00 


External Obscuration 

5.00% 

1.00 

1.11 


1.11 

0.00 


Transform AOI 

5.00% 

1.00 

1.11 


1.11 

0.00 


Generate Point Map 

25.00% 

5.00 

5.53 

2.48 

3.05 

2.24 

24.10% 

3D to 2D Projection 

15.00% 

3.00 

3.32 

0.62 

2.70 

0.56 

6.02% 

Chip & Texture 

15.00% 

3.00 

3.32 

2.17 

1.15 

1.96 

21.09% 

Final Image Proc. 

35.00% 

7.00 

7.75 

3.87 

3.88 

3.49 

37.58% 

Image Output 

0.00% 

0.00 

0.00 

1.15 

-1.15 

1.04 

11.21% 

Totals 

100.00% 

20.00 

22.14 

10.29 

11.85 

9.30 

100.00 

% 

Initialization 




30GM 


271.05 



6. Final Build Summary 

ARIES final build was a great success. The customer indicated overwhelming satisfaction with 
the product and with the Lockheed Martin TDS-Arizona ARIES team members. The following 
paragraphs discuss the outcome of the software integration. 

A software delivery was made to Northrop Grumman (NG) in June 97. This had constituted the 
“fixes” of Build 2. NG was given 10 days to integrate the software and inform LMTDS of a 
successful integration. Because no report was given on the status of the integration, LMTDS 
assumed all had gone well. It became evident two weeks prior to the last build (August 25) that 
NG had not integrated the Build 2 software fixes and was now encountering problems associated 
with trying to integrate it late in August. 

During Build 2, there was still some integration issues that dealt with the resolution of the 
display images and how both LMTDS and NG would treat those displays. Because it was not 
known ahead of time what the display size is in azimuth from run to run, it was agreed that 
Lockheed Martin would always return the same size image. It was up to NG to crop the image as 
needed to match the display size required. NG attempted to fix the resolution issue without 
success. The images were appearing skewed upon display at NG. Because this was not the case at 
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LM, clearly, it was a display function that needed to be fixed in NG display routines. LM 
provided all the detail of our processing via telephone and e-mail, and informed NG exactly what 
needed to be done on their end to fix the problem. Weeks passed with no response. To resolve 
this issue, LM funded an unscheduled trip for David Corgan to go to NG and fix this and any 
other problems (some of which were unknown) that occured. LM realized that the display ratio 
problem was a matter of NG passing the azimuth width in radians of the final image size, not of 
the size that ARIES passes back to the RPSI. 

While a number of items were identified for further analysis and possible future modifications, 
only one item was identified as a priority change. The target chips appeared too small to be 
visible on the NG display. Because they were deemed “too large” at LM the week prior, this was 
a surprising result. LM was also asked to remove the antenna “rolloff’ function that made the 
image appear darker as a function of azimuth. Because the rolloff boosted the targets to be more 
visible, removing it made them fade into the background. LM analyzed the images on our own 
system and remade the targets. The appearance of the targets in the images will not be verified 
until a set of images is executed at NG and send to LM for analysis. The displays are slightly 
different and ultimate verification is made by viewing on the NG system. 

NG had mentioned that the contrast ratio was not correct in the simulated images. NG offered the 
Signal-to-Noise ratio (SNR) as a “fix” to determing the proper contrast ratio. LM does not see the 
correlation between the value of the SNR and adjusting the contrast ratio based on this value. 
The contrast ratio between two areas of the image is a ratio of the image intensities in the two 
areas-not the signal-to-noise ratio. The contrast ratio of the simulated images matched that of the 
real images when measured on byte scaled data between shadow and flat terrain. The real images 
that were used as an example for the simulated images also were heavily attenuated due to a loss 
of antenna power across the image. Therefore, choosing an area that best described the area to 
emulate was a subjective matter. The contrast ratio of one area in the real data varied greatly 
from another. LM had requested the IQ data for each of the images. This would have provided 
the necessary absolute values of the clutter, targets, and noise that a single SNR value cannot 
provide. The images that LM were given were postprocessed through a weighted histogram 
equalization routine that distributed the byte scale detected data in a way that was unknown to 
LM. Therefore, going from this format to determining the IQ values would not be possible. The 
images were also provided without ground truth i.e., it was not known whether some of the 
targets were moving thereby appearing larger and brighter than normal. 

The following items were software fixes that occurred during integration and test at NG. 

1. CEP was divided by two to produce less error and be more characteristic of the system. 

2. Target chips were scaled to be brighter by a factor of 20 upon initialization. This was 
rectified by increasing the size of the targets. 

3. Antenna attenuation as function of azimuth was deleted. 
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4. New moving target response. The LM applied response did not visually match the 
processing that NG does for the real data, as no ground tmth has been delivered with the 
example images. NG “fixed” the moving target response by applying a phase error in an 
omnidirectional way with no regard for the aircraft velocity direction relative to target 
moUon. This is not an acceptable solution to LM for integration into ARIES and will be 
revisited at a later date. It is clearly NOT possible for the phase error to be omnidirectional. 
Phase errors due to uncompensated motion are visibly apparent in azimuth only. 

5. Targets and texture chips were “inserted” into background, not added. 

6. The elevation backgrounds were scaled down by a factor of 5 for dry lake beds and flat 
ground. 

^though the customer had accepted the above fixes as the critical modifications that needed to 

be done, LM identified the following modifications to include into Build 3. 

1. New Target chips implemented into library - remove scaling at initialization 

2. CEP divided by two is implemented in library 

3. Fix missing middle of runways 

4. Revisit the antenna rolloff procedure and address the image intensity without this process. 

5. Lower water level for more leading edge on shores 

6. Implement smooth soil background on orchards 

7. Verify possibility of missing target at end of list. 

identified during Build 3 delivery for modification during the next 

ARIES phase. 

1. Road beds for highways 

2. Implement variable quad tree depth 

3. GUI 

4. External Obscuration 

5. Shadow enhancements 

6. Terrain elevation grid registered with GRCA 
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7. Move CSCI-1 tables to library 

8. Enhanced testing display tool 

9. Moving target response 



APPENDIX F 


Interface Control Document 
for the 

Ground Station Module 
T-1 LAN Interface 
of the 

Radar Processor and Integrator 

for 

Joint STARS 


F- 1 



DOCUMENT NO. JADS ■ ICD - 002 
CODE IDENT: QOOl 
DATE: JANUARY 1997 

INTERFACE CONTROL DOCUMENT FOR THE GROUND 
STATION MODULE T-1 LAN INTERFACE 

OF THE 

RADAR PROCESSOR AND INTEGRATOR 

FOR 

JOINT STARS 

CONTRACT NO: 
prepared for: 

Joint Advanced Distributed Simulation 
Joint Test Force 

prepared by: 

Northrop Grumman 


F- 3 



TABLE OF CONTENTS 


1. Scope.. 

1.1 Purpose.. 

1.2 Application.. 

1.3 Definitions and Conventions. 7 

2 . Referenced Documents.. 

3. Message Definitions.. 

3.1 Messages To ADT. 9 

3.2 Control Messages.. 

3.2.1 Downlink Data Header. 9 

3.2.2 Aircraft Location... 11 

3.2.3 Polling Control.. 

3.3 Messages From The ADT. 12 

3.3.1 Transmit Vector Words.. 

3.3.2 Uplink Data Header.. 

3.3.3 Deleted Data.. 

3.3.4 Status .. 


F- 5 



















1. Scope 


This document defines the contents of the messages to and from the Ground Station Module 
(GSM) over a T-1 LAN interface for incorporation into the RADAR Processor Simulator and 
Integrator (RPSI) on the Joint STARS platform. 

1.1 Purpose 

The purpose of this document is to define the interface requirements between Northrop 
Grumman and Motorola regarding the RPSI. The RPSI is being developed for the integration of 
Joint STARS into the Joint Advanced Distributed Simulation (JADS) environment. 

1.2 Application 

Interface requirements set forth in this document apply during the development and laboratory 
testing of the RPSI. 

1.3 Definitions and Conventions 

The following conventions were used to describe each message interface: 

• High Level Message Elements 

a. Message Name. 

b. Brief functional description of the message. 

• Characteristics (Intermediate message elements): 

a. Source, Destination, Via, Transmission rate, and Size. 

b. Word Number 

c. Word Signal Name: either contains the actual field name or a functional name that best 
describes the fields within each message. 

d. Units: describes the engineering units to be applied against the word being described. 

e. MIN/MAX Range: describes the valid minimum and maximum range of values. If a 
single number is used, the min./max. Range is constant. If a number is enclosed 
parenthetically, (N), the number is ± N. The minimum and maximum range are evenly 
divisible by the least significant bit (LSB). Words that are encoded will have a min/max 
supplied as N/A. 
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f. Least Significant Bit (LSB): The LSB is defined to be bit 00, illustrated as the rightmost 
bit of a word. The LSB value is the weighting (scale factor) of the LSB. 

g. Type: this describes the FORTRAN data type that is applied to the word being described. 

Field Descriptions: 

a. Word Number: being described. 

b. Field name of field being described. 

c. Engineering Units, as described in the message Characteristics Table. Units can be 
described as bit encoded, meaning a bit map is required to fully define the field. Units 
can also be described value encoded, meaning the numeric value of the field means 
something other than the numeric itself. 

d. LSB (when applicable) is supplied describing the weighting of the least significant bit. 

e. Min/Max Range (when applicable) is supplied to describe the valid minimum and 

maximum range of the feild being described. 

Other Nomenclature: 

a. Spare Fields are noted in word pictures as “XX” fields. All spare fields are assumed 
to be zero. 

b. Most Significant Bit (MSB): The most significant bit is defined to be bit 15, shown as 
the leftmost bit of the word. 

c. Hexadecimal Representation: numbers represented in hexadecimal will be noted using a 
lower case “x”. For example the hex number OF will be shown as either ‘OF’x or OFx. 



2. Referenced Documents 


Document Number Title Date 

C99ICDVA345 The Airborne Data 06 January 1995 

Terminal (ADT) 

Surveillance and Control 
Datalink (SCDL) 

Producibility Program Joint 
Surveillance Target Attack 
Radar System (JOINT 
STARS) 


3. Message DeHnitions 

This section will identify those messages which will be supported by the RPSI and the added 
header information necessary for transmission over the T-1 LAN interface. The LAN interface 
will be a Standard 802.3 LAN and shall use the UDP protocol. 

3.1 Messages To ADT 

The following paragraphs contain the messages normally sent to the ADT by the 1553 bus 
controller. These messages in the normal system operations are described in the referenced ICD. 

3.2 Control Messages 

These messages are normally sent to the ADT by the E-8 1553 Bus Host and in general control 
the timing and priority of downlinked messages. The messages are Control, Adaptive Control A, 
and Adaptive Control B they will not be transmitted over the LAN. 

3.2.1 Downlink Data Header 

A downlink message is data normally received by the ADT, via the 1553 Bus, to be transmitted 
on the SCDL. The word formats as modified for retransmission on the T-1 are as follows: 
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Donwlink Data Header 

Message Name: Data Header 
Source: RPSI 
Destination: GSM 
Xmit Rate: Asynchronous 
Size: 29 Words 


Word 

Signal Name 

Units 

Range 

Init value 

LSB 

Type 

01 

Message ID 

ID 

9100x 

N/A 

1 

-£JclX 

1*2 

02 

Message Type 

Coded 

N/A 

N/A 

N/A 

1*2 

03 

GDT Address 

Coded 

N/A 

N/A 

N/A 

1*2 

04-29 

Data 

Coded 

N/A 

N/A 

N/A 

1*2 


Word 1 JADS Message ID this word is the JADS message identification. 

Word 2 — Bit 0-4 Message Type 

Bit 5-11 Serial Number. The value 0 is not a valid serial number. This fact is used by 
the receiving GDT to distinguish a Downlink message from a relay message. 

Word 3 — Bit 0 GDT Address 

Bit 1-2 Identifies the packet type as follows: 

00 = Report Packet 
01 = Dwell Packet 

10 = Object Packet 

11 = Single Packet 

Bit 3 is dependent upon the value of the Packet ID it is normally supplied by the ADT 
software and is defined as follows: 


When Packet ID equals: 


00 = Report Packet 
01 = Dwell Packet 

10 = Object Packet 

11 = Single Packet 


Bit 3 set indicates an acknowledgment is required. 

Bit 3 has no significance 

Bit 3 set indicates last packet of message. 

Bit 3 set indicates an acknowledgment is required. 


This BIT will not be simulated by the JADS T-1 LAN interface. 


Bits 4-15 Utility Field. User defined by the message originator (operator) to provide 
information to the GSM 1553 Bus Host about the downlink message. The 
definition of the information contained in this field is dependant on the value of the 

Packet ID and can be used by the GSM operator to obtain the following 
information: 
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When Packet ID equals: 


00 = Report Packet Utility Field contains the total count of Dwell or Object 
Headers in the message. 

01 = Dwell Packet Utility Field contains the serial number for the Dwell 
Packet. 

10 = Object Packet Utility Field contains the serial number for the Object 

Packet. 

11 = Single Packet Utility Field may contain data. 

Word 4-29 Data 

Bit 0-15 Data. 

3.2.2 Aircraft Location 

The Aircraft Location is a bus message containing the Latitude, Longitude, Altitude of the 
aircraft, the time delay and the current attitude of the aircraft in roll and pitch. The word formats 
as modified for retransmission on the T-1 are as follows: 

Aircraft Location 

Message Name: Aircraft Location 
Source: RPSI 
Destination: GSM 
Xmit Rate: Asynchronous 
Size: 9 Words 


Word Signal Name _ Units Range Init value LSB Type 


01 

Message ID 

ID 

9200x 

N/A 

1 

1*2 

02 

Latitude MSB 

DEG 

0-90 

N/A 

8.32x10'* 

1*2 

03 

Latitude LSB 

DEG 

0-90 

N/A 

8.32x10'* 

1*2 

04 

Longitude MSB 

DEG 

0-180 

N/A 

8.32x10* 

1*2 

05 

Longitude LSB 

DEG 

0-180 

N/A 

8.32x10* 

1*2 

06 

Altitude 

Meters 

32767.5 

N/A 

.5 

1*2 

07 

Time Delay 

msec 

2550 

N/A 

10 

1*2 

08 

Aircraft Roll 

DEG 

255.5 

N/A 

.5 

1*2 

09 

Aircraft Pitch 

DEG 

255.5 

N/A 

.5 

1*2 

Word 1- 

— JADS Message ID this word is the JADS message identification. 


Word2 

- Bit 0 Sign of Latitude. 0 

= North, 1 

= South. 





Bit 1 - 15, 15 Most Significant Bits of the aircraft latitude. (Note: the ADT truncates 
the data, using only the 6 MSBs of this word before downlinking to the GDT) 
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Word 3 Bit 0-15 Latitude, 16 Least Significant Bits of the aircraft latitude. 

Word 4 - Bit 0 Sign of Longitude. 0 = East, 1 = West. 

Bit 1 -15, 15 Most Significant Bits of the aircraft longitude. (Note: the ADT truncates 
the data, using only the 6 MSBs of this word before downlinking to the GDT) 

Word 5 - Bit 0-15 Longitude, 16 Least Significant Bits of the aircraft longitude 

Word 6 - Bit 0-15 Altitude, Aircraft Altitude. (Note: The ADT truncates the data using only the 
12 MSBs of this word before downlinking to the GDT). 

Word 7 - Bit 0-7 Spare 

Bit 8-15 Time Delay, the delay from the aircraft position measurement to its 
transmittal on the 1553 Bus to the ADT. 

Word 8 — Bit 0-6 Spare 

Bit 7-15 Aircraft Roll Angle, absolute value of roll angle. 

Word 9 — Bit 0-6 Spare 

Bit 7-15 Aircraft Pitch Angle, absolute value of pitch angle. 


3.2.3 Polling Control 

The polling control is sent to the ADT by the E-8 to establish the polling sequence (uplink 
channel assignment). The polling control message will not be transmitted on the T-1. 

3.3 Messages From The ADT 


This section contains those messages normally transmitted by the ADT to the Bus Host via the 
1553 data bus. 


3.3.1 Transmit Vector Words 

A message responding to a poll for uplink and relay data available from the ADT since last poll 
This message will not be used for the T-1 LAN implementation. 
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3.3.2 Uplink Data Header 

An Uplink Message is data normally received on the SCDL by the ADT. This message will 
received from the GSM via the T-1 LAN interface and processed by the RPSI. The format is as 
shown: 


Uplink Data Header 

Message Name: Uplink Data Header 

Source: GSM 

Destination: RPSI 

Xmit Rate: Asynchronous 

Size: 29 Words 


Word 

Signal Name 

Units 

Range 

Init value 

LSB 

Type 

01 

Message ID 

ID 

9300x 

N/A 

1 

1*2 

02 

Signal Strength 

Coded 

N/A 

N/A 

N/A 

1*2 

03 

H Fields 

Coded 

N/A 

N/A 

N/A 

1*2 

04 

Message Info 

Coded 

N/A 

N/A 

N/A 

1*2 

05-28 

Data 

Coded 

N/A 

N/A 

N/A 

1*2 

29 

Message Length 

Coded 

N/A 

N/A 

N/A 

1*2 


Word 1— JADS Message ID this word is the JADS message identification. 


Word 2 - Bit 0 -7 Signal Strength. Not used in JADS 
Bit 8 -15 Signal Quality. Not used in JADS 


Word 3— Bit 0 - 4 H Fields, are set by the ADT’s receiver hardware to provide 
information on the uplink message. Not used in JADS. 

Bit 5-15 Identifier, set to “1” to indicate an Uplink message. 

Word 4 - Bit 0-3 Data, first four bits of the message. 

Bit 4-8 Sender Address, valid addresses are 16,26, or 21 for an uplink. If monitor all 
uplinks bit is set addresses 1 through 15 are also valid (relay messages). 

Bit 14-15 message Code, designates the function of the message as follows: 

00 = No acknowledgment Required. 

01 = Acknowledgment Required. 

10 = Acknowledgment to Downlink packet or Relay message. 

11= Uplink acquisition message. 

Bit 14-15 will not be used in JADS. 

Word 5-28-Data. 
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Word 29 - Long Message 


Bit 0-2 Number of ACK Tries. Not used in JADS. 

Bit 3 Data Length, ignored by the ADT. Not used in JADS. 
Bit 4-15 Data. 

Short Message 

Bit 0-2 Number of ACK Tries. Not used in JADS. 

Bit 3 Data Length. Not used by JADS. 

Bit 4-15 Data. Valid only for long messages. 


3.3.3 Deleted Data 


A message m response to a command for the deleted data. The Deleted Data message provides 
the ADT operator with message type, serial number and deletion code for each downlink 

message that is deleted up to thirty-one messages. This message will not be implemented on the 
T-1 interface. 


3.3.4 Status 

The Status message provides the status information for the ADT. This message will not be 
implemented on the T-1 LAN interface. 
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1 SCOPE 


1.1 Identification 

This software test plan (STP) applies to the computer software configuration item (CSCI) portion 
of the Ground Data Terminal (GDT) 1553 Bus Interface Unit (1553 BIU). The development of 
the GDT 1553 BIU is under the direction of the Joint Advanced Development Simulation 
(JADS) Joint Test and Evaluation (JT&E) End-to-End Test (ETE) organization at Kirtland AFB 
in New Mexico. 

1.2 System Overview 

The JADS JT&E organization is charged with developing the capability to test and evaluate the 
Joint STARS system performance through a hardware-in-the-loop simulation. One element of 
this simulation is the interface between the Common Ground Station (CGS) and the E-8C 
aircraft. This interface is normally an RF link. The link is to be simulated by sending link data 
over a dedicated T1 line. This requires the development of interface software at both ends of the 
T1 line to make the data look like it had traversed the Surveillance Control Data Link (SCDL) 
rather than a WAN based digital connection. The specific software under test here is the 
interface software for the CGS end of the T1 line. 

1.3 Document Overview 

This STP describes the formal qualification test plans for the GDT 1553 BIU. It identifies the 
software test environment resources required for formal qualification testing (FQT) and provides 
schedules for FQT activities. In addition, it identifies the individual tests that shall be performed 
during FQT. 

1.4. Relationship to Other Plans 

There are no other plans related to this particular activity at the current contract level. 
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2. Referenced Documents 

Document Number Document Title Document Date 


JADS-ICD-002 

Interface Control Document for 
the Ground Station Module T-1 
LAN Interface of the Radar 
Processor and Integrator for Joint 
STARS 

January 1997 

C99ICDVA331 

Interface Control Document 
(ICD) for Ground Station Module 
(GSM) Target Acquisition 
Subsystem to Ground Data 
Terminal (GDT) Group OZ- 
64/GRY Containing LRU’s 
Nomenclatured (V)3/G 

15 April 1996 


3. Software Test Environment 


3.1 Software Items 

The software items necessary to perform the FQT activities include: 

Sun Solaris operating system. 

Sun C++ compiler, 

EDT 1553 device driver, 

GDT 1553 BIU application code, 

CGS 1553 test drivers, and 
ADT 802.3 test drivers. 

3.2 Hardware and Firmware Items 

The computer hardware, interfacing equipment, and firmware items that will be used in the 
software test environment include: 

Sun SPARC 5 computer (the application host). 

Sun computer (the 802.3 interface emulator). 

Sun computer (the 1553 interface emulator). 

Joint STARS Common Ground Station (CGS), 

IADS supplied IDNX, 

JADS supplied KIV-7HS, and 
JADS supplied CSU/DSU. 
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The test environment for CSCI testing will be unclassified. The test environment for system 
level testing may include classified information. Whether or not the system level test 
information is classified, the testing will include encryption / decryption equipment as part of the 
test setup. 

3.3 Propritary Nature and Government Rights 

There are no proprietary rights on the developed software, hardware, or firmware. 

3.4 Installation, Testing and Control 

The GDT 1553 BIU application code will be installed on the Sun SPARC 5 computer prior to 
test. The application code and all test software will be maintained under Configuration 
Management Version Control (CMVC) prior to and during the tests. 

4. Formal Qualification Test Identification 

4.1 GDT 1553 BIU CSCI 

4.1.1 General Test Requirements 

The formal qualification of the GDT 1553 BIU CSCI shall involve the use of nominal input 
values. Testing with erroneous input values will not be included. 

4.1.2 Test Classes 

The formal qualification testing of the GDT 1553 BIU CSCI shall include functional tests and 
timing tests. 

4.1.3 Test Levels 

The formal qualification testing of the GDT 1553 BIU CSCI shall be performed at two levels: 

a. CSCI level~to evaluate compliance with CSCI requirements. These tests include test 
definitions 4.1.4.1 through 4.1.4.9. 

b. System level--to validate that the SCDL interface performs properly in the absence of the real 
GDT. These tests will be similar in nature to the tests performed for CSCI testing, but they 
will generally be performed with real 1553 and 802.3 interfaces rather than the interface 
emulators used in the CSCI testing. These tests include test definitions 4.1.4.10 through 
4.1.4.14 


G-9 



4.1.4 Test Definitions 

4.1.4.1 GDT Initial Status 


a Test objective: Verify that the initial GDT status reports indicate that the uplink and 

downlink are not enabled and that the other status report elements are correct for this condition 

.K r this test, the 1553 emulator must not send a control message 

that enables the uplink or downlink. ° 

c. Test level: CSCI. 


d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: GDT Status Reports. 

g. Assumptions and constraints: None. 


4.1.4.2 GDT Initial Status Message Blocking 


1553 Bm*' traffic arc not passed through the GDT 

Ih ''O'- the 1553 emulator must not send a control message 

that enables the uplink or downlink. ° 

c. Test level: CSCI. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. T^e of data to be recorded: Presence or absence of uplink messages at the 802.3 interface 
or downlink messages at the 1553 interface. 

constraints: The 1553 interface emulator is sending uplink messages 
and the 802.3 emulator is sending downlink messages. 

4.1.4.3 GDT Initial Status Transition 


objective: Venfy that the GDT status reports indicate that the uplink and downlink 

are ena e after receipt of the uplink and downlink enabling control messages from the 1553 
emulator. 

b. requirements: For this test, the 1553 emulator must fust enable the downlink and 
then enable the uplink. 

c. Test level: CSCI. 


d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: GDT Status Reports. 

g. Assumptions and constraints: The GDT 1553 BIU 
Mode of paragraph 4.1.4.1. 


must start this test in the Initial Status 
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4.1.4.4 GDT Uplink Messages 

a. Test objective: Verify that uplink traffic is correctly passed through the GDT 1553 BIU. 

b. Special requirements: For this test, the 1553 emulator must have already enabled the 
uplink and downlink, 

c. Test level: CSCI. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: Uplink messages at the 802.3 interface. 

g. Assumptions and constraints: The 1553 emulator is providing periodic uplink messages. 

4.1.4.5 GDT Uplink Message Latency 

a. Test objective: Verify that uplink traffic is correctly passed through the GDT 1553 BIU 
with a latency of less than 100 milliseconds. 

b. Special requirements: For this test, the 1553 emulator must have already enabled the 
uplink and downlink. 

c. Test level: CSCI. 

d. Test type or class: Timing. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: Time of Uplink message appearance at the 1553 and 802.3 
interfaces. 

g. Assumptions and constraints: The 1553 emulator is providing periodic uplink messages. 

4.1.4.6 GDT Downlink Messages 

a. Test objective: Verify that downlink traffic is correctly passed through the GDT 1553 
BIU. 

b. Special requirements: For this test, the 1553 emulator must have already enabled the 
uplink and downlink. 

c. Test level: CSCI. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: Downlink messages at the 1553 interface. 

g. Assumptions and constraints: The 802.3 emulator is providing periodic downlink 
messages. 

4.1.4.7 GDT Downlink Message Latency 

a. Test objective: Verify that downlink traffic is correctly passed through the GDT 1553 
BIU with a latency of less than 100 milliseconds. 

b. Special requirements: For this test, the 1553 emulator must have already enabled the 
uplink and downlink. 

c. Test level: CSCI. 
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d. Test type or class: Timing. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: Downlink messages at the 1553 interface. 

g. Assumptions and constraints: The 802.3 emulator is providing periodic downlink 
messages. 


4.1.4.8 GDI Aircraft Location Messages 

a. Test objective: Verify that the Aircraft Location Message is correctly converted and 
passed through the GDT 1553 BIU in the GDT Status Report. 

b Special requirements: For this test, the 1553 emulator must have already enabled the 
uplink and downlink. 

c. Test level; CSCI. 

d. Test type or class; Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: GDT Status Reports at the 1553 interface. 

g. Assumptions and constraints: The 802.3 emulator is providing periodic aircraft location 
messages. 


4.1.4.9 GDT Traffic Capacity 

a. Test objective: Verify that GDT 1553 BIU traffic capacity is sufficient to pass 28 
Downlink mes^ges and one Uplink message, to process one Aircraft Location message, to 

provide one GDT Status message and two Transmit Vector Words messages during a 100 
millisecond time interval. b 

b Special requirements: For this test, the 1553 emulator must have already enabled the 
uplink and downlink. 

c. Test level: CSCI. 

d. Test type or class: Timing. 

e. Qualification method: Demonstration. 

f Type of data to be recorded: Time of Uplink message appearance at the 1553 and 802.3 
interfaces; time of Downlink message appearance at the 802.3 and 1553 interfaces; time of 
Aircraft Location messages appearance at the 802.3 interface; and time of GDT Status and TVW 
messages appearance at the 1553 interfaces. 

g. Assumptions and constraints: All required messages are provided to the GDT 1553 BIU 
CSCI at the proper rates. 

4.1.4.10 GDT Initial Status 


a. Test objective: Verify that the initial GDT status reports indicate that the uplink and 
downlink are not enabled and that the other status report elements are coirect for this condition 

b. Special requirements: For this test, the CGS must not send a control message that enables 
the uplink or downlink. 

c. Test level: System. 

d. Test type or class: Functional. 
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e. Qualification method: Demonstration. 

f. Type of data to be recorded: GDT Status Reports. 

g. Assumptions and constraints: None. 

4.1.4.11 GDT Initial Status Transition 

a. Test objective: Verify that the GDT status reports indicate that the uplink and downlink 
are enabled after receipt of the uplink and downlink enabling control messages from the 1553 
emulator. 

b. Special requirements: For this test, the CGS must first enable the downlink and then 
enable the uplink. 

c. Test level; System. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: GDT Status Reports. 

g. Assumptions and constraints: The GDT 1553 BIU must start this test in the Initial Status 
Mode of paragraph 4.1.4.7. 

4.1.4.12 GDT Uplink Messages 

a. Test objective: Verify that uplink traffic is correctly passed through the GDT 1553 BIU. 

b. Special requirements: For this test, the CGS must have already enabled the uplink and 
downlink. 

c. Test level: System. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: Uplink messages at the E-8C interface at Northrop / 
Grumman. 

g. Assumptions and constraints: The CGS is providing periodic uplink messages. 

4.1.4.13 GDT Downlink Messages 

a. Test objective; Verify that downlink traffic is correctly passed through the GDT 1553 
BIU. 

b. Special requirements: For this test, the CGS must have already enabled the uplink and 
downlink. 

c. Test level: System. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: Downlink messages at the CGS. 

g. Assumptions and constraints: The E-8C is providing periodic downlink messages. 
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4.1.4.14 GDT Aircraft Location Messages 

a. Test objective: Verify that the Aircraft Location Message is correctly converted and 
passed through the GDT 1553 BIU in the GDT Status Report. 

b. Special requirements: For this test, the CGS must have already enabled the uplink and 
downlink. 

c. Test level: System. 

d. Test type or class: Functional. 

e. Qualification method: Demonstration. 

f. Type of data to be recorded: GDT Status Reports. 

g. Assumptions and constraints: The E-8C is providing periodic aircraft location messages. 

4.1.5 Test schedule 


The testing of the GDT 1553 BIU CSCI shall be accomplished as soon as practical after this STP 
receives JADS ETE approval and dry-run testing verifies that the software passes the tests in 
paragraphs 4.1.4.1 through 4.1.4.9 of this STP. The system level testing of the GDT 1553 BIU 
CSCI shall be accomplished as soon as practical after completion of the CSCI level testing. The 
system level tests are defined in paragraphs 4.1.4.10 through 4.1.4.14. 

5. Data Recording, Reduction, and Analysis 

The data reduction and analysis required during and following the tests identified in this STP will 
be comparison of GDT Status Reports, Uplink Messages, and Downlink Messages with their 
respective expected values and evaluation of appropriate timing entries for message transmit and 
receipt. No data retention will be required other than logbook entries and printouts generated 
during the tests. 

6. NOTES 

None. 
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JADS BIU Qualification Test Procedure 


Three test configurations are identified herein to support the test levels and definitions described 
by the previously submitted Software Test Plan. This procedure describes each test configuration, 
tests conducted for that configuration, and a brief procedure for each test. All test definitions 
from the Software Test Plan are included within this procedure; however , they will be executed 
in accordance with the test configuration order presented below. 

Test Configuration I 

Software Emulation of CGS running on JADS BIU workstation 

JADS BIU Software running on JADS BIU workstation 

Software emulation of T1 Link running on “Kong” workstation 

Triax termination on Primary 1553 connector which links the CGS emulation software to the 
JADS BIU software via 1553 bus. 

Ethernet Link between JADS BIU and “Kong” network 

When each of the three software components have been initiated, the CGS Emulator will send 
control messages and uplink messages ( rate = 0.1 Hz) to the BIU over the 1553 bus, 
automatically triggering the GDT status transitions. The T1 link emulator software, upon 
receiving the first uplink message from the BIU over the Ethernet link, will respond by sending 
downlink messages (rate = 80 Hz) and aircraft location messages (rate = 1 Hz). When the JADS 
BIU software transitions to the downlink enabled mode, it will pass the messages through the 
1553 bus where they will be detected by the CGS Emulator software. Results of the tests will be 
verified by examination of log files generated as the above scenario is executed. 

Test Configuration I Coverage 

a) GDT Initial Status (STP Paragraph 4.1.4.1) 

Verify Control Word portion of initial GDT Status Report from CGS Emulator Log File 

b) GDT Initial Status Message Blocking (STP Paragraph 4.1.4.2) 

Examine JADS BIU Log File to verify that Uplink messages are counted only when Uplink is 
enabled, and that Downlink messages are counted only when downlink is enabled. 

c) GDT Initial Status Transition (STP Paragraph 4.1.4.3) 
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Examine JADS BIU Log File to verify that Uplink Enabled and Downlink 
transitions take place. 


enabled mode 


d) GDT Uplink Messages (STP Paragraph 4.1.4.4) 


“f messages passed through 

the JADS BIU and transmitted via Ethernet to the “Kong” workstation. 


e) GDT Uplink Message Latency (STP Paragraph 4.1.4.5) 


Examine JADS BIU Log 
milliseconds. 


File to record maximum and average Uplink latency values in 


f) GDT Downlink Messages (STP Paragraph 4.1.4.6) 

Ex^ne JADS BIU Log File to record maximum and average Uplink latency values in 


g) GDT Aircraft Location Messages (STP Paragraph 4.1.4.7) 


Examine CGS Emulator Log Files to verify the indication of Aircraft Location 
appropriate fields of the GDT Status message. 


data updating the 


Test Configuration II 


CGS Server 1553 connection to provide downlink data request 

JADS BIU Software running on JADS BIU workstation 

Software emulation of T1 Link running on “Kong” workstation 

Cable connection between Primary 1553 connector which links the CGS server to the JADS BIU 
software via 1553 bus. 


Ethernet Link between JADS BIU and “Kong” network 


Requests for downlink data are generated periodically (20 Hz) by the CGS Server The T1 link 
software emulation generates aircraft location & downlink messages at a rate which is 
comp^able to that supported by the actual T1 link maximum. Uplink messages will be generated 
from the CGS workstation console, and when the first message is passed through the JADS BIU 
to the T1 emulation software, downlink and aircraft location message transmission will begin. 
Results of the tests will be venfied by log files generated on the JADS BIU workstation. 


Test Configuration II Coverage 
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a) GDT Downlink Latency (STP Paragraph 4.1.4.7) 

Examine JADS BIU Log File to record maximum and average Downlink latency values in 
milliseconds. 

b) GDT Traffic Capacity (STP Paragraph 4.1.4.9) 

Examine JADS BIU Log File to record maximum throughput rate in messages per second. 

Test Configuration HI 

CGS Server 1553 connection to JADS BIU workstation 

E8 Aircraft Simulator Connection to JADS BIU workstation (Tl/ IDNX) 

The workstation will require re-configuration and re-boot to incorporate new IP address and port 
data, which are necessary to support its operational configuration. 

Test Configuration III Coverage 

a) GDT Initial Status (STP Paragraph 4.1.4.10) 

Capture GDT Status report at CGS Console using Bus Monitor Log facility. 

b) GDT Initial Status Transition (STP Paragraph 4.1.4.11) 

Use CGS Manage Links controls and periodic status displays on JADS BIU console to verily the 
status transitions. 

c) GDT Aircraft Location Messages (STP Paragraph 4.1.4.14) 

Use CGS Workstation Imagery window to display the simulated E - 8C flight path. 

d) GDT Uplink Messages (STP Paragraph 4.1.4.12) 

Generate RSR & Freetext messages using CGS Workstation and confirm receipt at Grumman 
facility. 

e) GDT Downlink Messages (STP Paragraph 4.1.4.12) 

Use CGS Message Alert facility to display Freetext message originated from the simulated E - 
8C ; use imagery window to display MTI & SAR imagery patterns. 
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APPENDIX H 


Memorandum for Record 
Characterization Reports 


From 


JADS JTF/ETE (N&E) 



MEMORANDUM FOR RECORD 


16 Dec 97 


FROM : JADS JTF/ETE(N&E) 

SUBJECT: Characterization Report 

1. Event Name: TCAC-Grumman T-1 Characterization. 

2. Date/Time: 1 Dec 97; 1100- 1500. 

3. Site(s): Grumman - Melbourne, FL; JADS TCAC - Albuquerque, NM. 

4. Description: The characterization involved base-lining the performance of the T-1 link 
between Grumman and the TCAC. A variety of Networking and Engineering tests were used to 
calculate the round trip latencies and determine the maximum rate at which DIS PDUs could be 
transmitted before drop-outs occurred. The tests used to gather this data included the No Load 
Latency Test, the Loaded Latency Test, PDU Verification Test and the Stress Test. Additionally, 
Spectrum recorded the bandwidth utilized across the T-1 link. 

5. Objective: Assess (characterize) the TCAC-Grumman T-1 Link with and without network 
analysis tools operating. 

5.1 Determine the “no load” latency using pings. 

5.2 Determine the loaded latency using pings at varying rates. 

5.3 Successful transmission of DIS PDUs across the link. 

5.4 Determine the packet rate (packets per second) in which DIS PDUs are lost. 

5.5 Determine the impact of Spectrum on latencies and data rates. 

6. Results: 

6.1. Data Recorded (with Spectrum operational) 

6.1.1 No Load Latency Test: The first test conducted was the no load latency test using 
pings. This test involved using 32 pings for measuring the baseline round trip latency from the 
TCAC to Grumman. The minimum load for these pings were 64 bytes. This test yielded the 
following results: 


Table 6.1.1. Latency Test - No Load 


Date 

Source 

Destination 

No. Pkts 

Round-trip Time (ms) I 

Minimum 

Maximum 

Average 

1 Dec 97 



32 

57 

71 

57 
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6.1.2. Loaded Latency Test; The second test consisted of transmitting loaded pings, 
144 bytes, at several different rates and packet sizes to determine the round trip latencies- see 
table 6.1.2. 


Table 6.1.2. Latency Test - Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Round 

-trip Time (ms) | 

Min 

Max 

Ave 

1 Dec 97 



.01 

320/320 

58 

163 

60 




.005 

640/639 

58 

61 

58 




.0025 

1280/1279 

58 

124 

58 




.00125 

2560/2559 

58 

167 

58 


6.1.3. PDU Verification Test: The next test used PDUs generated at 100 packets per 
second from JANUS and recorded by the IADS logger. The PDUs were replayed from the 
TCAC and logged at Grumman - see table 6.1.3. 


Table 6.1.3. PDU Verification Test 


Date 

Location 

No. of PDUs 
Received 

No. of PDUs 
Transmitted 

No. of PDUs 
Out-of-order 

No. of PDUs 
> 1 sec. 

5 Nov 97 

Grumman 

11859 

11859 

0 

0 




















6.1.4. Stress Test: This test involved replaying the ESPDU file at its recorded excepted 
data rate (EDR), then increasing the EDR by 100 packets per second incrementally to five times 
the EDR. During the actual playback of the PDU log file, pings were transmitted and latency 
statistics recorded. Spectrum also recorded the bandwidth utilized. 


Table 6.1.4. Stress Test 



Rate 

(PDU/sec) 

Ping Time (ms) 
Min/Max/Ave 

Number PDUs 
Received 

Bandwidth 

Util. (%) 

1 X E.R. 

100 

60/120/61 

11859 

10 

2 X E.R. 

200 

59/90/68 

11858 

21 

3 X E.R. 

300 

59/90/64 

11853 

28 

4 X E.R. 

400 

57/210/79 

11847 

40 

5 X E.R. 

500 

57/840/256 

10492 

45 


6.2. Data Recorded (without Spectrum operational) 

6.2.1 No Load Latency Test: The first test conducted was the no load latency test using 
pings. This test involved using Pipings for measuring the baseline round trip latency from the 
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TCAC to Grumman. The minimum load for these pings were 64 bytes. This test yielded the 
following results: 


Table 6.2.1. Latency Test - No Load 


Date 

Source 

Destination 

No. Pkts 

Round-trip Time (ms) | 

Minimum 

Maximum 


1 Dec 97 


EStSiiTH^TiVTifini 

32 

57 

76 

57 























6.2.2. Loaded Latency Test: The second test consisted of transmitting loaded pings, 
144 bytes, at several different rates and packet sizes to determine the round trip latencies- see 
table 6.2.2. 


Table 6.2.2. Latency Test - Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Round-trip Time (ms) | 

Min 

Max 

Ave 

1 Dec 97 



.01 

320/320 

58 

60 

58 




.005 

640/639 

58 

64 

58 




.0025 

1280/1279 

58 

101 

58 




^.00125 

2560/2559 

58 

161 

58 


6.2.3. PDU Verification Test: The next test used PDUs generated at 100 packets per 
second from JANUS and recorded by the JADS logger. The PDUs were replayed from the 
TCAC and logged at Grumman - see table 6.2.3. 


Table 6.2.3. PDU Verification Test 


Date 

Location 

No. of PDUs 
Received 

No. of PDUs 
Transmitted 

No. of PDUs 
Out-of-order 

No. of PDUs 
> 1 sec. 

5 Nov 97 

Grumman 

11859 

11859 

0 

0 




















6.2.4. Stress Test: The last test conducted was the Stress Test. The test involved 
replaying the ESPDU file at its recorded EDR, then increasing the EDR by 100 packets per 
second incrementally to five times the EDR. During the actual playback of the PDU log file, 
pings were transmitted and latency statistics recorded; however, bandwidth data was not 
collected. 
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Rate 

(PDU/sec) 

Ping Time (ms) 
Min/Max/Ave 

Number PDUs 
Received 

Bandwidth 

Util. (%) 

1 X E.R. 

100 

60/70/60 

11859 


2 X E.R. 

200 

58/92/62 

11858 


3 X E.R. 

300 

^ 59/89/63 

11853 


4 X E.R. 

400 

^ 57/120/71 

^ 11848 


5 X E.R. 

500 

57/600/216 

10759 



6.3. Problems; 


6.3.1. The characterization process was delayed for a couple of hours due to the 
monthly crypto reloading. 


6.3.2. During the PDU Verification test additional DIS PDUs were being logged at the 
Gmmmanjndy computer. The DIS PDUs logged at Grumman exceeded the number contained 
m the replayed log file sent from the TCAC. The Gmmmanjndy computer can receive data 
from both Grunman and the TCAC. The test coordinator contacted Gmmman and inquired as 
to whether they had a system broadcasting to the Gramman.Indy computer on port 3000. 

ramman s initial response to our question was no. Upon our investigation, which consisted of 
viewing traffic along port 3000, we observed the Gmmmanjndy computer receiving data long 
after we had stopped broadcasting. Apparently, Gmmman had concluded a test last week but 
their Alpha computer was still sending data to port 3000. Finally, Gmmman disconnected their 
Alpha computer and we resumed testing with no further problems or delays. 


j router card throughput is presently less than the vendor’s specification 

and the allocated capacity of the T-1 link. The performance can be improved if we used bridging 
^opposed lolntemcl Protocol (IP) routing of DIS PDUs. This procedure was assessed using the 
S testbed. The effect of bndging doubled the reliable transmitted data rate to 800 packets 
per second. However, this configuration does not support the current network design of the ETE 
test. The vendor was contacted about the shortcoming, and they are pursuing every avenue to 
determine if the performance problem is their software, Cisco's software, or hardware related. 


6.3.4 Although the utilized bandwidth was accurately recorded using Spectmm for one 
^o, and three times the EDR, the values for four and five times seemed lower than expected 
The percentages were 20 and 19, respectively. The data collection sampling interval was initial 
set for every 30 seconds. Consequently, the DIS PDUs were not replayed within the time 
window and the results were not representative of the EDR. The settings were reduced to 10 
second intervals and Spectmm’s packet rate data was monitored to ensure the values reflected the 


6.3.5. The maximum value recorded for each set of pings represented an outlier of the 
data set. This maximum value far exceeded the values recorded and consistently appeared at the 
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beginning of the recorded data set. Since this anomaly happened infrequently during a ping da ta 
set, the results were not statistically significant. N&E will continue to investigate this issue. 

6.4. Summary: At lOOOhrs the characterization team began the preliminary checks of the 
network. About one hour later, the characterization began and each one of the tests was executed 
in sequence. The test results were stable and fairly predicable. During the Stress Test several 
DIS PDUs were lost at three and four times the EDR but did not achieve a notable percentage. 
However, at five times the EDR several hundred DIS PDUs were dropped-approximately nine 
percent. Currently, the highest EDR transmissions across this link should not exceed 400 packets 
per second; therefore, the link can successfully handle the expected traffic. The characterization 
test also involved capturing the impact of the network analysis tool. The results indicated that 
Spectrum minimally increased the amount of network traffic and added an insignificant amount 
of latency. 


GREGORY P. DEWIT 
CPT(P), FA 
Test Analyst 
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MEMORANDUM FOR RECORD 


26 Feb 98 


FROM: JADS JTF/ETE/N&E 
SUBJECT: ETE Characterization Report 

1. Event Name: White Sands Missile Range (WSMR)/TCAC-A Annex T-1 Characterization. 

2. Date/Time: 3 Feb 98; 1100 - 1500. 

3. Sites: WSMR, NM; JADS TCAC - Albuquerque, NM. 

4. Description: The characterization involved base-lining the performance of the T-1 link 
between WSMR and the TCAC-A. A variety of Networking and Engineering tests were used to 
calculate the round trip latencies and determine the maximum rate at which DIS PDUs could be 
transmitted before drop-outs occurred. The tests used to gather this data included the No Load 
Latency Test, the Loaded Latency Test, PDU Verification Test, and the Stress Test. 

5. Objective: Assess (characterize) the WSMR/TCAC-A T-1 link. 

5.1 Determine the “no load” latency using pings. 

5.2 Determine the loaded latency using pings at varying rates. 

5.3 Successful transmission of DIS PDUs across the link. 

5.4 Determine the packet rate (packets per second) in which DIS PDUs are lost. 

6. Results: 

6.1. Data Recorded. 

6.1.1 No Load Latency Test: The first test conducted was the no load latency test using 
pings. This test involved using 32 pings for measuring the baseline round trip latency from the 
TCAC to WSMR. The minimum load for these pings were 64 bytes. This test yielded the 
following results: 


Table 6.1.1. Latency Test - No Load 


Date 

Source 

Destination 

No. Pkts 

Round-trip Time (ms) | 

Minimum 

Maximum 


1 Dec 97 



32 

41 

44 

41 


6.1.2. Loaded Latency Test: The second test consisted of transmitting loaded pings, 
144 bytes, at different rates and packet sizes to determine round trip latencies- see table 6.1.2. 
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Date 




Source 


Table 6.1.2. Latency Test - Loaded 


Destination 



Pkt 

Pkts 

Rounc 


OCll \J XvCC 

Min 

.01 

320/320 

42 

.005 

640/639 

r 42 

.0025 

^960/960 

42 


Max I Ave 


6.1.3. PDU Verification Test: The next test used PDUs generated at 100 packets per 

ft”"’ •ft" 

ICAC and logged at WSMR - see table 6.1.3. 


Date 
5 Nov 97 


Location 

WSMR 


Table 6.1.3. PDU Verification Test _ 

No. of PDUs No. of PDUs No. of PDUs No. of PDUs 

_ Received Transmitted Out-of-order > 1 sec. 

11859 I 11859 0 O""^— 


data rate ^SPOU file at its recorded excepted 

the FDR n ■ ’ ‘"""“‘"8 th® EDR by 100 packets per second incrementally to five times 

«atMe! r, h” H o ’’ 'ransn>i«ed Ini latency 

statistics recorded. Spectrum also recorded the bandwidth utilized. 


Rate (PDU/sec) 


1 X E.R. 

2 X E.R. 

3 X E.R. 

4 X E.R. 

5 X E.R. 


Table 6.1.4. Stress Test 
Ping Time (ms) 
Min/Max/Ave 
59/61/59 
41/61/59 
41/60/45 

_ 41/61/58 

41 / 70 ^ 


Number PDUs 
Received 
11859 
11858 
11853 
11850 
11849 


invettLte p“ to dm°outs''“' 

6.3. Summary: During the execution of the characterization, latencies and PDU drop-outs 
were less than anticipated. Unlike several other T-1 links characterized while using a roLd 
network confipration, WSMR used bridging. This technique provided a much m^e stable 
vironment thus allowing for lower transmission latencies and fewer PDU losses. Each 

wS^/rrlr^f? conducted and the results annotated in the previous tables. The 

MR/TCAC-A link can support the maximum expected data rate of 400 PDUs per second. 

GREGORY P. DEWIT 
CPT(P), FA 
Test Analyst 
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MEMORANDUM FOR RECORD 


26 Feb 98 


FROM : JADS JTF/ETE/N&E 
SUBJECT: Characterization Report 

1. Event Name: Fort Hood/TCAC-A Annex T-1 Characterization. 

2. Date/Time: 2 Feb 98; 0900-1100. 

3. Sites: Fort Hood, TX; JADS TCAC - Albuquerque, NM. 

4. Description: The characterization involved base-lining the performance of the T-1 link 
between Fort Hood and the TCAC-A. A variety of Networking and Engineering tests were used 
to calculate the round trip latencies and determine the maximum rate at which DIS PDUs could 
be transmitted before drop-outs occurred. The tests used to gather this data included the No Load 
Latency Test, the Loaded Latency Test, PDU Verification Test, and the Stress Test. 

5. Objective: Assess (characterize) the Fort Hood/TCAC-A T-1 link. 

5.1 Determine the “no load” latency using pings. 

5.2 Deterrmne the loaded latency using pings at varying rates. 

5.3 Successful transmission of DIS PDUs across the link. 

5.4 Determine the packet rate (packets per second) in which DIS PDUs are lost. 

6. Results: 

6.1. Data Recorded. 

6.1.1 No Load Latency Test: The first test conducted was the no load latency test using 
pings. This test involved using 32 pings for measuring the baseline round trip latency from the 
TCAC to Fort Hood. The minimum load for these pings were 64 bytes. This test yielded the 
following results: 


Table 6.1.1. Latency Test - No Load 


Date 

Source 

Destination 

No. Pkts 

Round-trip Time (ms) I 

Minimum 

Maximum 


1 Dec 97 

■iSSSSBiSH 

ISHifiPPPITiBB 

32 

37 

77 



6.1.2. Loaded Latency Test: The second test consisted of transmitting loaded pings, 144 
bytes, at several different rates and packet sizes to determine the round trip latencies- see table 
6 . 1 . 2 . 
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Table 6.1.2. Latency Test - Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Round 

-trip Time (ms) | 

Min 

Max 

Ave 

1 Dec 97 



.01 

320/320 

38 

39 

38 




.005 

640/639 

39 

55 

39 




.0025 

^ 960/960 

38 

76 

39 


6.1.3. PDU Verification Test: The next test used PDUs generated at 100 packets per 
second from JANUS and recorded by the JADS logger. The PDUs were replayed from the 
TCAC and logged at Fort Hood - see table 6.1.3. 


Table 6.1.3. PDU Verification Test 


Date 

Location 

No. of PDUs 
Received 

T wiiiiwaLiwii 

No. of PDUs 
Transmitted 

No. of PDUs 
Out-of-order 

No. of PDUs 
> 1 sec. 

5 Nov 97 

Fort Hood 

11859 

11859 

0 

0 


6.1.4. Stress Test: This test involved replaying the ESPDU file at its recorded excepted 
data rate (EDR), then increasing the EDR by 100 packets per second incrementally to five times 
the EDR. During the actual playback of the PDU log file, pings were transmitted and latency 
statistics recorded. Spectrum also recorded the bandwidth utilized. 


Table 6.1.4. Stress Test 



Rate (PDU/sec) 

Ping Time (ms) 
Min/Max/Ave 

Number PDUs 
Received 

1 X E.R. 

100 

40/69/59 

11859 

2 X E.R. 

200 

37/60/42 

11858 

3 X E.R. 

300 

r 50/60/59 

11853 

4 X E.R. 

400 

38/61/58 

r 11859 

5 X E.R. 

500 

37/61/54 

11859 


6.2. Problems: PDU drop-out is a reoccurring problem during the Stress Test N&E is still 
investigating. 


6.3. Summary: The Fort Hood/TCAC-A bridged link was characterized in less than four 
hours. The appropriate data was gathered and appears in the tables mentioned earlier There 
latencies were stable throughout the execution of each test. The link can support more than the 
maximum expected data rate with only a couple of PDUs dropped. A bridged network seems to 
offer faster transmission rates and fewer PDU drop-outs. 


GREGORY P. DEWIT 
CPT(P), FA 
Test Analyst 
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MEMORANDUM FOR RECORD 


26 Feb 98 


FROM : JADS JTF/ETE/N&E 
SUBJECT: Characterization Report 

1. Event Name: Fort Sill/TCAC-A Annex T-1 Characterization. 

2. Date/Time: 2 Feb 98; 1300 - 1600. 

3. Sites: Fort Sill, OK; JADS TCAC - Albuquerque, NM. 

4. Description: The characterization involved base-lining the performance of the T-1 link 
between Fort Sill and the TCAC-A. A variety of Networking and Engineering tests were used to 
calculate the round trip latencies and determine the maximum rate at which DIS PDUs could be 
transmitted before drop-outs occurred. The tests used to gather this data included the No Load 
Latency Test, the Loaded Latency Test, PDU Verification Test, and the Stress Test. 

5. Objective: Assess (characterize) the Fort Sill/TCAC-A T-1 link, 

5.1 Determine the “no load” latency using pings. 

5.2 Determine the loaded latency using pings at varying rates. 

5.3 Successful transmission of DIS PDUs across the link. 

5.4 Determine the packet rate (packets per second) in which DIS PDUs are lost. 

6. Results: 

6.1. Data Recorded. 

6.1.1 No Load Latency Test: The first test conducted was the no load latency test using 
pings. This test involved using 32 pings for measuring the baseline round trip latency from the 
TCAC to Fort Sill. The minimum load for these pings were 64 bytes. This test yielded the 
following results: 


Table 6.1.1. Latency Test - No Load 


Date 

Source 

Destination 

No. Pkts 

Round-trip Time (ms) I 

Minimum 

Maximum 


1 Dec 97 

TCACJndy 

Indy 

32 

30 

40 

30 1 


6.1.2. Loaded Latency Test: The second test consisted of transmitting loaded pings, 
144 bytes, at several different rates and packet sizes to determine the round trip latencies- see 
table 6.1.2. 
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Table 6.1.2. Latency Test - Loaded 


Date 

Source 

Destination 

Pkt 

Rate(sec) 

Pkts 

Sent/Rec 

Round 

-trip Time (ms) I 

Min 

Max 

Ave 

1 Dec 97 

TCACJndv 

Indy 

.01 

320/320 

31 

33 

31 




.005 

640/639 

31 

33 

31 




^ .0025 

r 960/960 

31 

33 

31 


6.1.3. PDU Verification Test: The next test used PDUs generated at 100 packets per 
s^ond from JANUS and recorded by the JADS logger. The PDUs were replayed from the 
TCAC and logged at Fort Sill - see table 6.1.3. 


Table 6.1.3. PDU Verification Test 


Date 

Location 

No. of PDUs 
Received 

T 1 Cl 

No. of PDUs 
Transmitted 

SI 

No. of PDUs 
Out-of-order 

No. of PDUs 
> 1 sec. 

5 Nov 97 

Fort Sill 

11859 

11859 

0 

0 


6 1 A. Stress Test: This test involved replaying the ESPDU file at its recorded excepted 
data rate (EDR), then increasing the EDR by 100 packets per second incrementally to five times 
t e EDR. During the actual playback of the PDU log file, pings were transmitted and latency 
statistics recorded. Spectrum also recorded the bandwidth utilized. 


Table 6.1.4. Stress Test 



Rate (PDU/sec) 

Ping Time (ms) 
Min/Max/Ave 

Number PDUs 
Received 

1 X E.R. 

100 

30/61/58 

11859 

2 X E.R. 

200 

30/60/52 

11857 

3 X E.R. 

300 

30/61/43 

11853 

4XE.R. 

400 

30/60/36 

11859 

5 X E.R. 

500 

30/84/300 

10656 


6.2. Problems: PDUs were lost during the execution of the Stress Test. N&E will continue 
to investigate packet drop-outs. 


6.3. Summary: The Fort Sill/TCAC-A link involved using a router to transmit PDU packets. 
The latencies were reasonably close to the values during the Grumman Characterization given 
the shorter distance between Albuquerque and Fort Sill. There were a couple of packets lost 
while incrementing up to four times the EDR. The number of lost PDUs increased to about 10 
percent of the packets transmitted at five times the EDR (500 packets per second) 


GREGORY P. DEWIT 
CPT(P), FA 
Test Analyst 
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Joint Advanced Distributed Simulation Joint Test Force 
(JADS JTF) 


LWX and Cisco Router Performance Test Report 


SUBJECT: 


AUTHOR: 


DATE: 


Integrated Digital Network Exchange 
(IDNX) LANAVAN Exchange (LWX) and 
Cisco Router Performance Measurement in the 
Broadcasting/Forwarding of 
User Datagram Protocol Environment 

MSgt Charles P. Ashton, WAN Systems 
Engineer, Joint Advanced Distributed 
Simulation (JADS) Joint Test Force (JTF) 

Mason S. Ferratt, Systems Engineer 
Network Equipment Technologies (NET) 

December 18,1997 


SUMMARY: This is a report of the performance, validation, and 

verification testing conducted on the LWX and external Cisco router platforms at the JADS-JTF 
facility, Albuquerque, NM. This document covers the steps taken during testing, the test results, 
conclusions drawn, and a discussion of the alternative solutions for the broadcasting of User 
Datagram Protocol (UDP) traffic through the JADS JTF End-to-End (ETE) network. 
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1. Background 


The Joint Advanced Distributed Simulation Joint Test Force (JADS JTF) has built a network of 
seven nodes to support an environment linking multiple simulation sites whose primary 
application is the broadcasting of User Datagram Protocol packets from multiple sites to multiple 
sites. The network supports the evaluation of Advanced Distributed Simulation (ADS) for the 
Department of Defense (DOD) Test and Evaluation (T&E) Community. The system is called the 
End-to-End Test Network and the system under test is the Joint Surveillance and Targeting 
Attack Radar System (JSTARS) and its associated command and control functions. The services 
carried by this network include the router traffic and voice traffic. 

The goal of the testing conducted December 15-16, 1997 was to provide answers to whether the 
PX platforms (PX-3, PX-2, and APX) provided by NET could support the demands of the UDP 
traffic load through the JADS network. 

2. Scope of Testing 

1. Verification/validation of the problems witnessed by TSGT Ashton 

2. Comparison of the performance gains/losses of external router configurations 

3. Effects of altering internal software configuration (buffers, hold queues, etc.) 

4. Effects of using a hybrid routed/bridged network 

5. Effects of a completely bridged network 

3. Description of PX-3 and LWX Rel. 3.01 

The LANAVAN Exchange (LWX) Release 3.01 is a general purpose router/bridge integrated into 
the Integrated Digital Network Exchange (IDNX) platform. It provides internetwork connectivity 
between Local Area Networks (LANs) over Wide Area Networks (WANs) through IDNX/ 90, 
no, /20, and /Micro 20 IDNX nodes. The LWX 3.01, consists of a PX3 front card (revision B or 
later) and an Ethernet or Token Ring interface rear card, and provides: 

— concurrent multi-protocol routing and fallback Media Access Control (MAC) layer bridging 

— up to 8 logical serial connections to other LWXs or external routers 

— an Ethernet interface rear card 

The first phase of LWX 3.01 only supports four and eight port PX3 cards. Earlier LWX versions 
consisted of a PX- 2, PX- Plus, or Access PX front card and an Ethernet or Token Ring interface 
rear card, and provide only eight logical serial connections to other LWXs or external routers. 
LWX Release 3.01 supports only Ethernet and Token Ring (available in a later release) interface 
cards. LWX Release 3.01 must use a revision B (or later) PX3 card. 

The JADS network uses four port PX3, eight port PX-2, and four port APX cards. The PX-3s 
run LWX Release 3.01 and the PX-2s and APXs run LWX Release 2.02.06. The LWX Release 
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3.01 is equivalent to Cisco’s lOS Release 11.0(9). The LWX Release 2.02.06 is equivalent to 
Cisco’s lOS Release 9.1(9). ^ 

4. Test Configurations 


Classified Unclassified 



Figure 4-1 - JADS EXE Network Configuration 


Figure 4-1 above illustrates a general configuration of the JADS ETE network. The connectivity 
between the nodes remained consistent throughout the testing. However, card and port 
configurations were varied for the different tests. 

4.1 Point to Point PX-3 

IDNX-20 IDNX-20 

w/PX-3 w/PX-3 



Figure 4.1-1 - PX-3 to PX-3 Configuration 















Figure 4.4-1 - Cisco 7000 to PX-3 Configuration 
























Figure 4.4-1 above illustrates the setup used for the verification/validation using an externally 
connected Cisco 7000 running Cisco lOS Release 11.x to a PX-3 point-to-point. The Cisco 7000 

was serially connected through an HSD-2 port on the IDNX. The HSD-2 port was mapped to the 
distant end PX-3. 



Figure 4.5-1 - Cisco 7000 to Cisco 4000 Configuration 

Figure 4.5-1 above illustrates the setup used for the verification/validation using an externally 
connected Cisco 7000 running Cisco lOS Release 11.x to another externally connected Cisco 

routers were serially connected through HSD-2 ports on the 
IDNX. The HSD-2 ports were mapped end to end. 

4.6 Multipoint UDP Forwarding & Hybrid Bridge/Router 



Broadcaster 


Broadcaster 


Figure 4.6-1 - Multipoint UDP Forwarding & Hybrid Bridge/Router Configuration 


Figure 4.6-1 above illustrates the setup used for the verification/validation using multiple sources 
to broadcast DIS Entity State PDUs to a central logger. This configuration represents a portion 
of the unclassified side of the JADS ETE network. 
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5. Test Expectations 


Throughout all the tests the Broadcaster, an SGI Indy workstation, used a file that consisted of 
11,859 Distributed Interactive Simulation (DIS) Entity State protocol data units (PDUs). The 
SGI workstation broadcasted the PDUs on its local area network (LAN) as User Datagram 
Protocol (UDP) packets. The LWXs were configured to forward these broadcasts through the 
network. Each Entity State PDU was 144 bytes in length. The Internet Protocol (IP) datagram 
produced was 152 bytes in length. All this was verified using a Network General Sniffer 
Protocol Analyzer on the Broadcaster subnetwork. 

At the distant end, the Logger, also an SGI Indy workstation, listened for UDP broadcasts and 
counted the number received. The difference is the number of packets dropped within the 
network. 

We expected to see a threshold that each platform would reach in terms of performance. We 
knew that the unreliable nature of the traffic (UDP broadcasts) would force the routers to inspect 
each packet since it was a broadcast, and forward it onto each interface. This activity is known 
as process switching. The fact that every packet sent is process switched, we knew there had to 
be a limit to the number of packets successfully received when a workstation floods the network. 
We also expected to see very little improvement when changing the buffers and hold-queues. 
The fact remained that if packets are process-switched, there is a finite limit to speed in which it 
forwards packets successfully. We will discuss more about these issues in our conclusions. 

The following two sections cover the result sets for the two separate environments (point-to- 
point and multipoint). The point-to-point environment results were used to gauge the expected 
results when we combined multiple stations broadcasting in the network. The multipoint 
configuration better represents the true network that will be fielded to support the JADS ETE 
network. 

6. Performance Test Results (Point to Point - UDP forwarding) 

Broadcaster generating 400 packets per second - 





JK«toPX-3 

0 

■0, 

PX-3toAPX 

0 

0 

Cisco 4000 to PX-3 

0 

0 

Cisco 7000 to PX-3 

0 

0 

Cisco 4000 to Cisco 7000 

0 

0 

Cisco 7000 to Cisco 4000 

0 

0 
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Broadcaster generating 500 packets per second 


Configuration 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Logger Side) 

Bx-atopx-s 

2366 

0 

PX-3toAPX 

2366 

0 

Cisco 4000 to PX-3 

0 

2366 

Cisco 7000 to PX-3 

0 

2366 

Cisco 4000 to Cisco 7000 

0 

0 

Cisco 7000 to Cisco 4000 

0 

0 


Broadcaster generating 600 packets per second 


Configuration 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Logger Side) 

PX-3 to PX-3 

3927 

0 

PX-3toAPX 

3927 

0 

Cisco 4000 to PX-3 

0 

3927 

Cisco 7000 to PX-3 

0 

3927 

asco 4000 to Cisco 7000 

0 

0 

Cisco 7(X)0 to Cisco 4000 

0 

0 


Broadcaster generating 700 packets per second 


Configuration 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Logger Side) 

PX-3 to PX-3 

4722 

0 

PX-3toAPX 

4722 

0 

Cisco 4000 to PX-3 

0 

4722 

Cisco 7000 to PX-3 

0 

4722 

Qsco 4000 to Cisco 7000 

0 

0- 

Cisco 7000 to Cisco 4000 

0 

0 











Broadcaster generating 800 packets per second 


Configuration 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Log}>er Side) 

PX-3 to PX-3 

5646 

0 

.PX-3toAPX 

5646 

0 . 

Cisco 4000 to PX-3 

623 

5023 

Cisco 7000 to PX-3 

0 

5646 

Cisco 4000 to Cisco 7 OOO 

623 

0 

Cisco 7000 to Cisco 4000 

0 



Broadcaster generating 900 packets per second 


Configuration 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Logger Side) 

PX-3 to PX-3 

6239 

-0" ' 

PX-3toAPX 

6239 

0 

Cisco 4000 to PX-3 

1717 

4522 

Cisco 7000 to PX-3 

276 

5963 

Cisco 4000 to Cisco 7000 

1717 

0 

Cisco 7000 to Cisco 4000 

116 

0 


7. Performance Test Results (Multipoint - UDP Forwarding) 

Due to the limited resources and the overall intention of the testing, we restricted the multipoint 
tests to the PX platforms. The question to be answered was whether the PX-3 would respond the 
same way as the point to point test but with various interfaces transmitting broadcast traffic. 
With two broadcasting spoke sites and a single logger hub site we got the following results: 
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Broadcaster generating 400 packets per second (aggregate) - one site transmitting at 200 pps and 
a second site transmitting at 200 pps. 


Confij’unition 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Loeeer Side) 

PX-3 Hub/PX-3 Spokes 

0 

,0 

PX-3Hub/ APX Spokes 

0 

0 

Cisco 4000 to PX-3 

Not Tested 

Not Tested 

Cisco 7000 to PX-3 

Not Tested 

Not Tested 

Cisco 7000 toi Cisco 4000 

Not Tested 

Not Tested 


Broadcaster generating 500 packets per second (aggregate) - one site transmitting at 300 pps and 
a second site transmitting at 200 pps. 


Configuration 

Packets Dropped 
(Broadcast Side) 

Packets Dropped 

(Logger Side) 

PX-3 Hub / PX-3 Spokes 

0 

2366 

PX-3 Hub/APX Spokes 

0 

2366 

Cisco 4000 to PX-3 

Not Tested 

Not Tested 

Cisco 7000 to PX-3 

Not Tested 

Not Tested 

1 Cisco 7000 to Cisco 4000 

Not Tested 

Not Tested 


As expected, the aggregate broadcast traffic at the hub site creates the same results. The total 
process-switching capacity for the PX platform is limited and independent of the interfaces used. 

8. Hybrid Bridge/Router Configuration 

One configuration that we were able to test was a hybrid bridge/router configuration. Our testing 
was restricted to the unclassified portion of the network. In this configuration the two spoke 
locations bridged the serial and Ethernet interfaces. In the hub location, we utilized bridging on 
the unclassified interfaces and routing for the serial interface going over to the classified portion 
of the network. With this configuration we were able to successfully pass an aggregate of 600 
pps to the logger off the ethemet interface of the hub node. The same file was broadcast from 
two different bridge segments, so the total number of PDUs broadcast was 23718 packets. 
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Broadcaster generating 600 packets per second (aggregate) - one site transmitting at 300 pps and 
a second site transmitting at 300 pps. 


Configuration 

Packets Dropped Packets Dropped 

(Broadcast Side) (Logger Side ) 

;PX-3 Hub/PX-3 Spokes 

0 

0 

PX-3 Hub/APX Spokes 

0 

0 

Cisco 4000 to PX-3 

Not Tested 

Not Tested 

Cisco 7000 to PX-3 

Not Tested 

Not Tested 

Cisco 4000 to Cisco 7000 

Not Tested 

Not Tested 

Cisco 7000 to Cisco 4000 .; 

Not Tested 

Not Tested 


Broadcaster generating 700 packets per second (aggregate) - one site transmitting at 300 pps and 
a second site transmitting at 400 pps. 


Configuration 

Packets Dropped Packets Dropped 

(Broadcast Side) (Logger Side) 

PX-3 Hub/PX-3 Spokes 

0 

2594 of 23718 sent 

PX-3 Hub/APX Spokes 

0 

2594 of 23718 sent 

Cisco 4000 to PX-3 

Not Tested 

Not Tested 

Cisco 7000 to PX-3 

Not Tested 

Not Tested 

Cisco 4000 to Cisco 7000 

Not Tested 

Not Tested 

Cisco 7000 to Cisco 4000 

Not Tested 

Not Tested 


Further testing must be done to verify the effects on the traffic sent over the serial connection to 

the classified logger. 

9. Conclusions 

• The limitations uncovered during the testing involved the level of process switching capacity 
on the PX-3, the Cisco 4000, and the Cisco 7000. 

• The use of UDP - an inherently unreliable transport mechanism - is not always a suitable 
choice of transport for data that needs a high level of reliability. The transmission control 
protocol (TCP) is better suited for reliable transport since it uses sequencing and 
acknowledgments, but at a cost of increased latency - which was not tested. Also, the use of 
multicasting or unicasting would take advantage of the fast switching capability of all the 
routers tested. 
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• The use of broadcast based networking has an adverse effect on the network. Routing this 
traffic adds one additional layer of processing (especially when the broadcasts are process 
switched) and creates multiple copies of each datagram in order to forward it to multiple 
network subnets. Thus, congesting the network with broadcast traffic. Since the key 
application relies on broadcasts, we should consider flattening the network and use bridging. 

• definitive “break points” where the processors could not handle anymore packets 
This IS true on every platform tested. 

• During the testing, we did notice that there were drops on the hold-queue, missed buffer 
requests, and fallbacks on the interface buffers. To remedy this we added to the hold-queue 
len^h and increased the number of permanent big buffers. The actual number of successful 
packets sent never rose above the initial ceiling. In other words, the addition of buffers and 
increasing the hold-queue did not affect, in any way, the speed at which the processor 
process-switched the packets. This was expected. 

is with the router’s processor handling UDP broadcasts. 
With UDP broadcast traffic, all packets are process switched. With unicast and multicast 
tr^fic, the router is capable of fast switching most of the packets. Routers gain efficiencies 
when they are capable of caching routes for packets. 

• We had discussions with Technical Assistance Center Staff Engineers from both NET and 
Cisco Systems over the last two weeks. Engineers from both companies stated that none of 

their router platforms have ever been tested to find what are the limits of reliable transport of 
UDP packets. ^ 

• configuration relies on the broadcaster. If the network has to reliably transport 
UDP broadcasts above 400 pps (aggregate) to the hub node to be logged then a PX-3/APX 
routed solution will not suffice. 

10. Recommendations 

The initial requirements of the JADS ETE network included a broadcaster transmitting 100 
packets per second. All of the configurations tested will satisfy this requirement. Only when the 
aggregate packet load on the PX-3 (using UDP forwarding) exceeded 400 packets per second 
was there a concern for lost/dropped packets. With bridging, this ceiling was up to 800 packets 
per second. If the JADS ETE network is to continue using broadcasted UDP packets with a 
small number of sites, bridging would be a better solution. Options and limitations are as 


Routim 


PX-3/APXs - 400 pps aggregate limitation 

External Cisco 4000 Routers at each site (serially connected via HSD-2s) - up to 700 pps 
aggregate limitation; higher cost ^ 
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Bridging 


PX-3/APXs - 800 pps aggregate limitation 

Hybrid Routing/Bridging 

PX-3/APXs - 600 pps aggregate limitation 

Several issues have to be addressed (weighing the pros and cons): 

• Broadcasting at lower rates. 

• Pro: Limiting the speed of the broadcasts to under a 400 pps aggregate would ensure the 
ability to forward all of the UDP traffic through the network. 

• Con: The impact of slower rates on the simulation is unknown. 

• The use of multicasting in the future. 

• Pro: The use of multicasting would take advantage of the router’s ability to fast switch 
the traffic. The router only has to process switch the first packet to find the route and will 
stream the following data along the same route. 

• Con: Finding a suitable data logger may be difficult or a logger would have to be written, 
and the impact on the simulation is unknown. 

• Bridging the entire network. 

• Pro: The use of bridging would increase the reliable throughput of UDP traffic to 
approximately 800 pps. However, this option should be further tested on the entire JADS 
ETE network. 

• Con: Speed of transmission is higher, but still limited to 800 pps. Also, it may be 
difficult to persuade all sites to be part of the same subnet. 

• The cost of using external routers. 

• Pro: Different router platforms have different processing power. There are other 
platforms that have better performance in forwarding UDP packets. 

• Con: There are tangible limitations where the processors could not handle process 
switched traffic - regardless of platform. Candidate platforms should be tested for this 
application before procurement. Also, cost is a factor. Costing information is 
unavailable at this time, but it is safe to state that the more powerful the processor, the 
higher the cost. 
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APPENDIX A. ACRONYMS/DEFINITIONS 

Advanced Distributed Simulation 
Distributed Interactive Simulation 


DOD 

IP 

JADS JTF 

JSTARS 

LAN 


Department of Defense 

Internet Protocol: The network layer for the TCP/IP Protocol Suite. 

JOINT ADVANCED DISTRIBUTED SIMULATION JOINT TEST FORCE 
Joint Surveillance Targeting and Attack Radar System 
Local Area Network 


Media Access Control: The lower portion of the datalink layer. 

MAC-Layer Bridge A device that connects two or more similar networks in a way that is 
transparent to the users of the network layer. 

Op®** Systems Interconnection: The seven layer suite of protocols to be 
the international standard computer network architecture. 


POU Protocol Data Unit: An OSI term for “packet.” A PDU is a data object 

exchanged by protocol machines (entities) within a given layer. 

PPS Packets Per Second 


T&E 


Test and Evaluation 


Transmission Control Protocol: An Internet standard transport protocol 
in the Internet protocols suite for reliable, connection-oriented, full-duplex 
streams. 


P USER DATAGRAM PROTOCOL: An Internet standard transport protocol 

that exchanges datagrams without acknowledgments or guaranteed delivery. 

WAN Wide Area Network 


All Definitions are from G uide to Networking and Internetworking Terms Simoneau, Paul, © 1993, American Group, Cary NC 
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APPENDIX J 


Acronyms and Abbreviations 


J- 1 


AAR 

ACE 

ADS 

AFATDS 

ALQ-131 


ALSP 

ANIU 

AOI 

ARIES 

ARPA 

ASAS 

ATACMS 

ATWS 

BBS 

BIU 

bps 

C4I 

C4ISR 

CAMPS 

CBS 

CDP 

CEP 

CGS 

Cisco 

CPI 

CPU 

deg or ° 

DEAD 

DIS 

DISNIU 

DMA 

DoD 

DPDU 

DT 

DT&E 

DIED 

EAGLE 


Appendix! - Acronyms and Abbreviations 

after action report/review 

analysis and control element 

advanced distributed simulation 

Advanced Field Artillery Tactical Data System 

a mature self-protection jammer system; an electronic countermeasures 

system with reprogrammable processor developed by Georgia Tech 

Research Institute 

aggregate level simulation protocol 

air network interface unit 

area of interest 

Advanced Radar Imaging Emulation System 
Advanced Research Projects Agency 
All Source Analysis System 
Army Tactical Missile System 
Advanced Technology Work Station 
Brigade Battalion Simulation 
bus interface unit 
bits per second 

command, control, communications, computers and intelligence 
command, control, communications, computers, intelligence, 
surveillance and reconnaissance 

Compartmented ASAS (All Source Analysis System) Message 

Processing System 

Corps Battle Simulation 

central data processor 

circular error probable 

common ground station 

Cisco Systems, Inc. 

coherent processing interval 

central processing unit 

degree 

digital feature analysis data 

distributed interactive simulation 

distributed interactive simulation network interface unit 

Defense Mapping Agency 

Department of Defense 

detonation protocol data unit 

developmental testing 

developmental test and evaluation 

digital terrain elevation data 

a rule-based tactical simulation developed by the U.S. Army Training and 
Doctrine Command (TRAC), Leavenworth, Kansas 
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ECEF 

ES 

ESPDU 

ETE 

EW 

FDC 

Force 


FPDU 
ft or ’ 

FTI 

FY 

GDI 

GIS 

GNIU 

GPC 

GRCA 

GSM 

HA 

hh 

HLA 

I&Q 

ID 

IDNX 

IP 

mis 

JAAWS 

JADS 

JanDIS 

JanPVD 

Janus 

JCM 

JFS 

Joint STARS 

JT&E 

JTF 

km 

LAN 

LAOI 

LFP 

LSP 

LWX 

m 


earth centered earth fixed 
entity state 

entity state protocol data unit 
End-To-End Test 
electronic warfare 
fire direction center 

a menu option that opens the Scenario Forces Editor which is used to 

modify system numbers, aggregation, and task force assignments for a 
Janus scenario 

fire protocol data unit 
feet 

fixed target indicator 
fiscal year 

ground data terminal 
Geographical Information System 
ground network interface unit 
general purpose computer 
ground reference coverage area 
ground station module 
heterogeneous aggregation 
hour 

high level architecture 

in-phase and quadrature (radar data) 

identification 

Integrated Digital Network Exchange 
internet protocol 

intemetted range interactive simulations 
Janus analyst workstation 

joint advanced distributed simulation or Joint Advanced Distributed 
Simulation, Albuquerque, New Mexico 
Janus Distributed Interactive Simulation 
Janus Plan View Display 

interactive, computer-based simulation of combat operations 
joint conflict model 

joint feasibility study or JADS Joint Feasibility Study 
Joint Surveillance Target Attack Radar System 
joint test & evaluation 

joint test force or Joint Test Force, Albuquerque, New Mexico 
kilometer 

local area network 
live area of interest 
live fly phase 
linked simulators phase 

local area network/wide area network exchange 
meter 
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M&IS 

MB 

Mbps 

MIL-STD 

mm 

MODSAF 

MOT&E 

MPDU 

MPSP 

ms 

MTI 

NIU 

OT 

OT&E 

Pd 

PDU 

PEA 

PSP 

rad 

RAM 

RCU 

RDO 

RDP 

RISS 

RPS 

RPSI 

RSB 

RSG 

RSR 

s / ss / sec 

S/N 

SAR 

SCDL 

SGI 

SIT 

SM&C 

SMO 

SPECTRUM 

sq 

STAGE 


STRICOM 

SWA 

T&E 


management and integration software 
megabyte 

megabits per second or millions of bits per second 
military standard 
minute 

Modular Semi-Automated Forces 
multi-service operational test and evaluation 
message protocol data unit 
modified programmable signal processor 
millisecond 

moving target indicator 
network interface unit 
operational test 
operational test and evaluation 
probability of detection 
protocol data unit 
probability of false alarm 
programmable signal processor 
radian 

reliability, availability and maintainability; random access memory 

radar control unit 

radar data operational 

radar data processor 

Radar Image Simulation System 

radar processor simulation 

radar processor simulator and integrator 

radar sensor bus 

radar sensor group 

radar service request 

second 

signal-to-noise ratio 
synthetic aperture radar 
surveillance control data link 
Silicon Graphics, Inc. 

System Integration Test 
system management and control 
system management officer 

an instrumentation suite used to measure bandwidth utilization 
square 

Scenario Toolkit and Generation Environment - scripted simulation by 

Virtual Prototypes, Inc., that is used to build complex simulations and 

graphically define interactive tactical scenarios 

U.S. Army Simulation, Training, and Instrumentation Command 

Southwest Asia 

test and evaluation 
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T-1 


TAC 

TAFSM 

TC 

TCAC 

TCP 

TCS 

TEXCOM 

TRAC 

TRADOC 

u.s. 

U-2R 

UAV 

UDP 

V&V 

VDP 

VSTARS 

VV&A 

WAN 

WGS-84 

WSMR 

XE.R. 

XPATCHES 


digital carrier used to transmit a formatted digital signal at 1.544 

megabits per second 

target analysis cell 

tactical Army fire support model 

target classification 

Test Control and Analysis Center, Albuquerque, New Mexico 

transmission control protocol 

topocentric coordinate system 

U.S. Army Test and Experimentation Command 

U.S. Army Training and Doctrine Command (TRADOC) Analysis 
Center 

U.S. Army Training and Doctrine Command 

United States 

surveillance aircraft 

Unmanned Aerial Vehicle 

user datagram protocol 

verification and validation 

VSTARS data packet 

Virtual Surveillance Target Attack Radar System 

verification, validation, and accreditation 

wide area network 

World Geographic System 1984 

White Sands Missile Range 

times expected rate 

E-8C synthetic aperture radar simulation developed by Wright 

Laboratory, Dayton, Ohio, and Loral Defense Systems, Goodyear, 
Arizona 
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